Skip to content

[Fix] Coding tasks reply directly when Fast owns the conversation - #1804

Draft
roomote-roomote[bot] wants to merge 1 commit into
developfrom
fix/orchestrator-chat-replies-1a9kfw041efpl
Draft

[Fix] Coding tasks reply directly when Fast owns the conversation#1804
roomote-roomote[bot] wants to merge 1 commit into
developfrom
fix/orchestrator-chat-replies-1a9kfw041efpl

Conversation

@roomote-roomote

Copy link
Copy Markdown
Contributor

​Opened on behalf of @daniel-lxs. Follow up by mentioning @roomote-roomote, in the web UI, or in Slack.

What changed

  • makes orchestrator report ownership the provider-neutral authority for suppressing direct coding-task chat replies
  • prevents older or partially migrated Fast child payloads from receiving direct Slack, Discord, Microsoft Teams, or Telegram reply environment variables and user-facing chat instructions when they retain a valid Fast parent but lack communicationContextInherited
  • keeps direct-user coding tasks reply-capable and preserves structured input controls, provider task routing, active-task continuation, and identityless automation fallbacks
  • adds focused shared and worker routing coverage for all four chat providers, explicit/legacy report consumers, Fast-parent inference, and direct-user payloads

Why this change was made

Fast owns user communication for orchestrator-delegated coding tasks, but direct reply suppression previously depended only on the newer communicationContextInherited flag. Persisted or partially migrated child payloads can still be recognized through reportConsumer or fastAgentParent; treating those existing signals as authoritative prevents duplicate or out-of-band coding-task replies.

Impact

Orchestrator-owned coding tasks report only to their parent session across Slack, Discord, Teams, and Telegram, including older payload shapes. Direct chat tasks continue using their existing provider reply paths. This PR does not change provider intake: draft PR #1792 continues to own Teams Fast-first task entry, Telegram intentionally retains normal inbound task routing, and Slack/Discord bot or webhook auto-starts retain their existing identityless fallback policy.

Validation

  • focused routing and lifecycle tests: Slack 34, Discord 121, Teams 77, Telegram 72
  • shared suppression, worker MCP environment, structured input callback, and cloud-agent reporting tests: 50
  • full pnpm lint
  • full pnpm check-types
  • pre-push oxlint, residual lint, fast type checks, and knip
  • git diff --check

@roomote-community

roomote-community Bot commented Aug 28, 2026

Copy link
Copy Markdown
Contributor

No code issues found. See task

Reviewed a1933b9

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant