#5514: Slack: fix threadId ignored on read + thread_broadcast dropped
channel: slack
Cluster:
Slack Thread ID Fixes
## Summary
- **Bug 1 (#2454):** The Slack extension's `action=read` handler was not passing `threadId` through to `handleSlackAction`. Added the missing `threadId` param in `extensions/slack/src/channel.ts`.
- **Bug 2 (#4351):** Messages with `subtype === "thread_broadcast"` (thread replies sent with "Also send to channel") were dropped because the handler returned early after logging a system event. Removed the early `return` in `src/slack/monitor/events/messages.ts` so these messages fall through to `handleSlackMessage`.
Closes #2454, Closes #4351
## Test plan
- [x] `pnpm build` passes
- [x] `pnpm vitest run src/slack/ extensions/slack/` — all 126 tests pass
- [ ] Manual: send a thread broadcast in Slack and verify it's processed
- [ ] Manual: read messages with a `threadId` param via the extension and verify thread messages are returned
🤖 Generated with [Claude Code](https://claude.com/claude-code)
<!-- greptile_comment -->
<h2>Greptile Overview</h2>
<h3>Greptile Summary</h3>
This PR fixes two Slack message handling regressions:
- In the Slack extension channel plugin, the `action=read` handler now forwards `threadId` into the `readMessages` tool payload so threaded reads can be scoped correctly.
- In the core Slack monitor message event handler, `thread_broadcast` messages no longer return early after logging a system event; they now continue through the shared `handleSlackMessage(...)` path, preventing these user-visible messages from being dropped.
Both changes are small and localized, and they align the extension adapter behavior with the existing core Slack actions adapter implementation.
<h3>Confidence Score: 5/5</h3>
- This PR is safe to merge with minimal risk.
- Changes are narrowly scoped (one added param passthrough and one removed early return) and they restore intended Slack behavior without altering interfaces or control flow beyond the specific bug conditions; the extension change matches existing core adapter behavior and there are no new edge cases apparent in the touched code paths.
- No files require special attention
<!-- greptile_other_comments_section -->
**Context used:**
- Context from `dashboard` - CLAUDE.md ([source](https://app.greptile.com/review/custom-context?memory=fd949e91-5c3a-4ab5-90a1-cbe184fd6ce8))
- Context from `dashboard` - AGENTS.md ([source](https://app.greptile.com/review/custom-context?memory=0d0c8278-ef8e-4d6c-ab21-f5527e322f13))
<!-- /greptile_comment -->
Most Similar PRs
#14720: fix(slack): pass threadId in plugin read action (#14706)
by lailoo · 2026-02-12
87.9%
#6509: fix(slack): pass threadId param in read action
by morningstar-daemon · 2026-02-01
86.3%
#22216: fix(slack): enable thread reply reading in slack extension plugin
by lan17 · 2026-02-20
85.7%
#5098: fix(slack): forward threadId for message.read
by galligan · 2026-01-31
84.7%
#22485: fix(slack): use threadId from delivery context as threadTs fallback...
by dorukardahan · 2026-02-21
82.1%
#19083: Slack: preserve per-thread context and consistent thread replies
by jkimbo · 2026-02-17
81.2%
#2917: Slack: fix thread context + prevent reply spillover
by SocialNerd42069 · 2026-01-27
81.0%
#20406: fix(slack): respect replyToMode when computing statusThreadTs in DMs
by QuinnYates · 2026-02-18
79.3%
#4749: fix: handle string thread IDs in queue drain for Slack
by nvonpentz · 2026-01-30
79.2%
#22874: fix(slack): preserve numeric threadId for message read
by HarryMWinters · 2026-02-21
78.8%