When Slack POSTs a block_actions payload (a Block Kit button click) inside a thread, the parent thread is in payload.container.thread_ts (and mirrored in payload.message.thread_ts). Master ignores both — handleInteractiveRequest only passed slackChannelId to getBotpressConversationFromSlackThread, so the integration created a brand-new (channel) conversation per click instead of routing the synthesized message into the thread's existing conversation. Bots' replies then landed in the channel root instead of the thread, even with replyBehaviour.location: 'thread' configured.

Cloud-log evidence (production bot 'bot-auditor-adk', UTC):

  17:53:26.588  Slack POSTs block_actions payload (URL-encoded body starts with payload=%7B%22type%22%3A%22block_actions%22... container.thread_ts present)

  17:53:30.034  Bot starts running in conv_01KQWMBZBQ9X8Y3YA6NPVBJ24N (NEW conversation). The original 'hello' thread used conv_01KQWM1N0CVNDP4R2KFYH2V1X5.

  17:53:48.464  Bot reply lands in channel root, not the thread.

Fix: extract thread_ts via a new getInteractiveThreadTs helper that reads container.thread_ts ?? message.thread_ts, then pass it to getBotpressConversationFromSlackThread. The helper covers block_actions today and the same shape applies to view_submission / message_action payloads. getBotpressConversationFromSlackThread now passes discriminateByTags: ['id', 'thread'] when upserting the threaded conversation, matching the existing pattern in message-received.ts so distinct threads in the same channel don't collide.

Side-effect cleanup: type 'InteractiveBody' relaxed to mark response_url, actions, channel, and message as optional (Slack genuinely omits these for some interactive shapes), with explicit RuntimeError throws when a required field is actually missing. Reordered the 'unsupported interaction type' guard before _respondInteractive so view_submission / message_action / shortcut payloads short-circuit cleanly without sending an empty response_url POST.

Test plan: vitest case 'routes block_actions messages to the Slack thread conversation when container.thread_ts is present' confirms the new path; 'keeps top-level block_actions messages on the existing channel conversation path' verifies no regression for non-threaded clicks; 'getInteractiveThreadTs prefers container.thread_ts over message.thread_ts' and 'extracts message.thread_ts for view_submission and message_action style payloads without a container thread' lock down the helper. Verified: with the fix all 13 tests in the slack package pass; without the fix (production code reverted) 3 of the new 4 tests fail with the exact error patterns operators saw in production. eslint clean. Pre-existing typecheck errors in slack-manifest-client.ts and message-received.ts are present on master too and are unrelated to this fix.

Addresses Greptile review feedback on #15162.

1. _parseInteractiveBody used `String.replace('payload=', '')` which strips the first occurrence of that substring anywhere in the body. Slack's URL-encoded callbacks always carry the prefix, but the same handler is reachable via the raw-JSON `/interactive` path; a JSON value containing the literal text `payload=` would have been silently corrupted there. Replaced with anchored-prefix slicing via a small _stripPayloadPrefixIfPresent helper whose name encodes the invariant.

2. Added six negative-path tests: short-circuit on non-block_actions interaction types, RuntimeError throws when actions / response_url / channel id / message ts are absent, and a regression test that a raw JSON body containing 'redirect=payload=baz' inside an action value parses correctly without stripping the embedded payload= substring.

All 19 tests in the slack package now pass; pnpm --filter @botpresshub/slack run check:lint clean.

…l path

Self-audit: the previous `actions: []` case already threw on master via `!body.actions.length` — testing it here didn't add unique coverage. Switched to `actions: undefined`, which only became reachable after this PR relaxed the type to `actions?: [...]` and added optional chaining to the guard. Same error message asserted; now the test actually exercises a behavior change.

…ractive handlers

Per review: the previous commit replicated message-received.ts's dispatch logic inline in interactive-request.ts. That's duplication — both handlers now call a single getReplyDispatch helper in misc/utils.ts that owns the (slackThreadTs, slackMessageTs, replyLocation) -> (isSentInChannel, shouldRespondInChannel, shouldRespondInThread, threadTsForReply) computation.

Same idea for body parsing. _parseInteractiveBody used to roll its own anchored prefix-strip (PAYLOAD_PREFIX + _stripPayloadPrefixIfPresent) — but utils.ts already had safeParseBody doing the same thing. Switched the interactive handler to delegate to safeParseBody so there's exactly one place to keep correct.

No behavior change. interactive-request 13/13 tests still green; signature-validator 4/4; replace-mentions 5/5; total 22/22. message-received has no tests in this package, but its refactored block is mechanically equivalent: the helper produces the exact same booleans + threadTs the inline code computed.

… don't collapse

Greptile P1: discriminateByTags ['ts','channelId'] used the button-message timestamp as the identity key. Unlike a normal Slack message — where each ts maps to one user message — a block_actions ts is the *button* message's ts, which multiple users can click. The runtime would find the existing record on user-B's click and silently drop it.

Fix: discriminator is now ['ts','channelId','userId','forkedToThread'] for every interactive dispatch. userId makes each user's click its own Botpress message; forkedToThread keeps the channelAndThread dual-dispatch path distinct (channel branch and thread branch differ on that tag). Always-include is also more robust against ordering — earlier code branched on (forkedToThread === 'false' && isSentInChannel) which would have returned the existing thread-message record if the thread branch ran first under channelAndThread.

Test added: 'discriminates inbound messages by userId so distinct users clicking the same button do not collapse onto one Botpress message' — locks both the userId tag and the discriminator array shape, which is the actual contract the runtime keys off.

Also: the previous CI run-checks failure ('Delete \`\u23ce\u00b7\u00b7\u00b7\`') was a prettier complaint about a multi-line shouldRespondInThread expression in misc/utils.ts. pnpm fix:format collapsed it to one line (under the 120-char printWidth).

23/23 slack tests pass; oxlint and eslint both clean.