openclaw - 💡(How to fix) Fix [Bug]: Slack adapter silently swallows boot-time auth.test failure, breaking explicit <@bot> mention detection [1 pull requests]

Summary

The Slack adapter's startup auth.test call is wrapped in a silent try/catch in extensions/slack/src/monitor/provider.ts. If it fails for any reason (bad token, transient network error, rate limit), botUserId stays "" for the life of the process and the failure is invisible in logs.

Downstream, the explicit <@bot> mention check in prepare.ts is:

const explicitlyMentionedBotUser = Boolean(
  params.ctx.botUserId && params.mentionedUserIds.includes(params.ctx.botUserId),
);

With botUserId === "", this is always false, so direct <@bot> mentions in channels are classified as non-mentions and the bot ignores them. The user sees a bot that has silently stopped responding to direct mentions, with no error trace in the gateway logs.

Bug type

Behavior bug (incorrect output/state without crash).

Steps to reproduce

1. Start OpenClaw with a Slack channel adapter configured.
2. Force the boot-time auth.test to fail — easiest way: temporarily set SLACK_BOT_TOKEN to a revoked or invalid token. (Real-world triggers include transient Slack API outages, token rotation, or hitting auth.test rate limits during a flap.)
3. In a Slack channel where the bot is a member, send <@<bot-id>> ping.
4. Inspect the inbound metadata for that message.

Expected behavior

• A warning log line at boot indicating auth.test failed and explicit-bot detection is degraded.
• After fixing the token and restarting, explicit <@bot> mentions are detected normally.

Actual behavior

• No warning log line at boot. The failure is silent.
• <@bot> messages get explicitly_mentioned_bot=false, mention_source="none", and a populated mentioned_user_ids (the regex scrape runs independently of botUserId, so the bot's id does appear there). The asymmetry between "we collected this id from the text" and "the bot was not explicitly mentioned" is the visible symptom.

Root cause

extensions/slack/src/monitor/provider.ts, around the boot auth.test:

try {
  const auth = await app.client.auth.test({ token: botToken });
  botUserId = auth.user_id ?? "";
  // ...
} catch {
  // auth test failing is non-fatal; message handler falls back to regex mentions.
}

The comment is aspirational: there is no functioning fallback path. prepare.ts's explicit-bot check short-circuits to false whenever botUserId is empty, and nothing else in the pipeline recovers it.

Affected files

• extensions/slack/src/monitor/provider.ts (silent catch swallows the failure)
• extensions/slack/src/monitor/message-handler/prepare.ts (explicit-bot check depends on botUserId)

Proposed fix

PR follows. Two-part fix:

1. Surface auth.test failures with a boot-time warn log so the degraded state is observable. Also treat an empty user_id from a successful auth.test as a failure.
2. Normalize both sides of the explicit-bot mention equality through the existing normalizeSlackId helper (already in subteam-mentions.ts) so the collected ids and the ctx bot id flow through one normalizer. Real Slack ids are already uppercase so this is a no-op on healthy traffic, but it removes the asymmetry between the two normalization paths.

Plus regression tests pinning both the positive case (botUserId set → explicit_bot) and the negative case (botUserId="" → not explicit_bot).

Environment

• OpenClaw: main (verified against current main HEAD)
• Channel: Slack (Socket Mode)
• Repro path: rotating/invalidating the Slack bot token and restarting.