When the Slack adapter's startup auth.test call fails (bad token,
transient error, etc.), the bot user id silently stays empty for the
life of the process. The downstream explicit-bot mention check is
`botUserId && mentionedUserIds.includes(botUserId)`, which always
returns false when botUserId is empty. The result is that explicit
<@bot> mentions are silently classified as non-mentions with no log
trace explaining why.
Changes:
- provider.ts: stop swallowing auth.test failures; emit a warn log at
boot so the degraded state is observable. Empty user_id is treated
as a failure too.
- prepare.ts + subteam-mentions.ts: export the existing normalizeSlackId
helper and apply it to both sides of the explicit-bot equality check
(and to the mentioned-ids list). Real Slack ids are already uppercase,
so this is a no-op on healthy traffic, but it locks the invariant down
and removes the asymmetry between collected ids and the ctx bot id.
- prepare.test.ts: add two regression tests pinning the exact symptom:
positive case (botUserId set -> explicit_bot), negative case
(botUserId='' -> not explicit_bot, mention_source not explicit_bot).
🤖 AI-assisted.
Co-authored-by: in-liberty420 <in-liberty420@users.noreply.github.com>
* fix(slack): route DM thread replies to main session instead of thread-scoped session
DM thread replies (user replies inside a thread under a bot message in a
DM) were routed to a thread-specific session key instead of the user's
main DM session. This caused the agent to never receive the inbound on
the expected session, making the bot appear unresponsive.
The root cause was in prepare-routing.ts: canonicalThreadId for
isDirectMessage was set to threadTs when isThreadReply was true, creating
a session key like agent:main:slack:direct:u3🧵<ts>. DM threads
are a UI affordance — not a session boundary — so all DM messages should
route to the main DM session regardless of thread_ts.
Also adds a diagnostic logVerbose warning when assistant_app_thread
message_changed events fail sender resolution (Case 2 of #82390),
which was previously completely silent.
Fixes#82390
* chore(slack): polish DM thread routing PR
* test(slack): update DM thread routing contract
* test(slack): flatten non-main DM thread expectations
* fix(slack): preserve bound DM thread routes
* test(slack): align DM thread session fixtures
* fix(slack): keep flattened DM thread metadata scoped
* fix(slack): preserve DM thread delivery routes
---------
Co-authored-by: Peter Steinberger <steipete@gmail.com>
Route Discord and Slack prepared message turns through the core prepared-turn runner directly.
Local proof before landing:
- node scripts/run-vitest.mjs src/channels/turn/kernel.test.ts extensions/discord/src/monitor/message-handler.process.test.ts extensions/slack/src/monitor/message-handler/prepare.test.ts extensions/slack/src/monitor/message-handler/dispatch.preview-fallback.test.ts
- node scripts/run-tsgo.mjs -p tsconfig.core.json --incremental false
- node scripts/run-tsgo.mjs -p tsconfig.extensions.json --incremental false
- OPENCLAW_TESTBOX_REMOTE_RUN=1 OPENCLAW_VITEST_MAX_WORKERS=1 pnpm check:changed
- codex-review clean after accepted Slack bot-loop history cleanup finding was fixed in core
GitHub checks had no failures; Blacksmith/GitHub runner jobs were still queued when maintainer approved landing based on local proof.
