#21218: fix(slack): pass recipient_team_id and recipient_user_id to chat stre…

…aming The Slack chat.startStream API requires recipient_team_id and recipient_user_id when streaming in channels. Without these parameters the stream fails with "missing_recipient_team_id" or "missing_recipient_user_id" errors, causing the bot to silently drop channel replies. ## Summary Describe the problem and fix in 2–5 bullets: - Problem: - Why it matters: - What changed: - What did NOT change (scope boundary): ## Change Type (select all) - [x] Bug fix - [ ] Feature - [ ] Refactor - [ ] Docs - [ ] Security hardening - [ ] Chore/infra ## Scope (select all touched areas) - [ ] Gateway / orchestration - [ ] Skills / tool execution - [ ] Auth / tokens - [ ] Memory / storage - [x] Integrations - [ ] API / contracts - [ ] UI / DX - [ ] CI/CD / infra ## Linked Issue/PR - Closes # - Related # ## User-visible / Behavior Changes List user-visible changes (including defaults/config). If none, write `None`. ## Security Impact (required) - New permissions/capabilities? (`No`) - Secrets/tokens handling changed? (`No`) - New/changed network calls? (`No`) - Command/tool execution surface changed? (`No`) - Data access scope changed? (`No`) - If any `Yes`, explain risk + mitigation: ## Repro + Verification ### Environment - OS: - Runtime/container: - Model/provider: - Integration/channel (if any): Slack (channel, no DM) - Relevant config (redacted): ### Steps 1. Send a message to the bot in a Slack channel (not a DM) 2. Observe the bot attempting to reply via streaming 3. ### Expected - The bot streams its response in real time in the thread ### Actual - chat.startStream fails with missing_recipient_team_id, fallback delivery kicks in (or reply is dropped entirely) ## Evidence Attach at least one: - [ ] Failing test/log before + passing after - [x] Trace/log snippets - [ ] Screenshot/recording - [ ] Perf numbers (if relevant) ## Human Verification (required) What you personally verified (not just CI), and how: - Verified scenarios: - Edge cases checked: - What you did **not** verify: ## Compatibility / Migration - Backward compatible? (`Yes`) teamId and userId are optional; if absent, behavior is identical to before - Config/env changes? (`No`) - Migration needed? (`No`) - If yes, exact upgrade steps: ## Failure Recovery (if this breaks) - How to disable/revert this change quickly: git revert 05c33b297 - streaming falls back to normal delivery - Files/config to restore: chat.startStream errors in logs, non-streamed replies - Known bad symptoms reviewers should watch for: ## Risks and Mitigations List only real risks for this PR. Add/remove entries as needed. If none, write `None`. - Risk: - Mitigation: <!-- greptile_comment --> <h3>Greptile Summary</h3> Adds `recipient_team_id` and `recipient_user_id` parameters to Slack's `chat.startStream` API call to fix "missing_recipient_team_id" and "missing_recipient_user_id" errors when streaming in channels. The fix passes `ctx.teamId` and `message.user` to the stream initialization in `dispatch.ts:197-204`. <h3>Confidence Score: 4/5</h3> - Safe to merge - addresses a specific API requirement with minimal risk - The changes correctly implement required Slack API parameters for streaming in channels. The fix is narrowly scoped to the streaming functionality and uses existing context values. The conditional parameter passing protects against missing values. Minor concern about the `|| undefined` pattern potentially hiding empty string values, but `ctx.teamId` is typed as required string. - No files require special attention _{Last reviewed commit: 05c33b2} <!-- greptile_other_comments_section --> _{(2/5) Greptile learns from your feedback when you react with thumbs up/down!} <!-- /greptile_comment -->