Bug Description

Slack gateway can become completely unresponsive while the Hermes gateway process still appears healthy/running. In this state, Slack messages receive no response until hermes gateway restart is performed.

From debugging logs and the current code, the likely root cause is that SlackAdapter.connect() marks Slack as connected before Socket Mode has actually established a live WebSocket session, and failures in the background Socket Mode task are not propagated back into the gateway's fatal-error / reconnect logic.

This leaves a bad state where:

• process is still running
• gateway status still looks healthy
• Slack Socket Mode is dead / stuck reconnecting internally
• inbound Slack messages are silently ignored
• manual restart recovers it

Symptoms Observed

• Slack messages sent to Hermes got no response in any DM/thread window
• hermes gateway status still reported the gateway service as running
• restarting the gateway restored Slack responsiveness

Relevant Logs / Traceback

The most relevant evidence for the unresponsive window was around 2026-04-23 04:24 KST.

Observed in ~/.hermes/logs/agent.log:

2026-04-23 04:20:57,213 INFO slack_bolt.AsyncApp: The session (s_289228377) seems to be stale. Reconnecting... reason: disconnected for 51+ seconds)
2026-04-23 04:20:57,814 INFO slack_bolt.AsyncApp: The old session (s_289228377) has been abandoned
2026-04-23 04:20:58,284 INFO slack_bolt.AsyncApp: A new session (s_282243233) has been established
2026-04-23 04:21:38,291 INFO slack_bolt.AsyncApp: The session (s_282243233) seems to be already closed. Reconnecting...
2026-04-23 04:21:45,153 INFO slack_bolt.AsyncApp: The old session (s_282243233) has been abandoned

Then there is a gap with no successful new session establishment while Slack was observed to be unresponsive. The next relevant lines are:

2026-04-23 04:26:45,181 ERROR slack_bolt.AsyncApp: Failed to connect (error: ); Retrying...
...
TimeoutError
2026-04-23 04:26:55,222 INFO slack_bolt.AsyncApp: The old session (s_282243233) has been abandoned
2026-04-23 04:26:55,729 INFO slack_bolt.AsyncApp: A new session (s_289885077) has been established

So there appears to have been a real Slack Socket Mode disruption from roughly 04:21:45 until 04:26:55, and the user-observed unresponsive time (04:24 KST) fell inside that gap.

This issue is not about a previously observed invalid_auth event. That was from a separate later incident caused by intentionally incorrect credentials and should not be treated as the direct cause of this report.

Current Code Path

Current gateway/platforms/slack.py still does this:

# Start Socket Mode handler in background
self._handler = AsyncSocketModeHandler(self._app, app_token)
self._socket_mode_task = asyncio.create_task(self._handler.start_async())

self._running = True
logger.info("[Slack] Socket Mode connected (%d workspace(s))", len(self._team_clients))
return True

This means the adapter returns success immediately after spawning start_async(), before actual Socket Mode establishment has been confirmed.

Why This Is Problematic

start_async() eventually calls Slack SDK socket-mode connect logic, but that work happens in a background task. If that task fails, retries for a while, or ends up in a stale/closed/reconnect loop, Hermes has already:

• marked the adapter as connected
• returned success from connect()
• allowed the gateway to continue as if Slack were healthy

I could not find code that:

• waits for Socket Mode establishment before setting _running = True
• attaches a done-callback to _socket_mode_task
• converts background Socket Mode task failure into _set_fatal_error(...) / _notify_fatal_error()
• downgrades platform state when the Slack background task dies after startup

So the gateway can enter a "running but Slack is dead" zombie state.

Expected Behavior

One of the following should happen:

1. SlackAdapter.connect() should only return success after Socket Mode is actually established, or
2. background Socket Mode task failure should be promoted into the gateway fatal-error / reconnect path

In either case, Hermes should not remain in a state where the process looks healthy while Slack is functionally dead.

Actual Behavior

• Slack becomes unresponsive
• gateway process remains running
• gateway status still looks fine
• no automatic self-recovery occurs
• manual hermes gateway restart is needed

Affected Component

• Gateway (Telegram/Discord/Slack/WhatsApp)

Messaging Platform (if gateway-related)

• Slack

Operating System

macOS

Python Version

3.11.11

Hermes Version

Hermes Agent v0.10.0 (2026.4.16)

Root Cause Analysis (optional)

Likely root cause:

• gateway/platforms/slack.py treats asyncio.create_task(self._handler.start_async()) as a successful connection
• Slack SDK connection/auth/websocket failures happen later inside the background task
• those failures are not surfaced into Hermes gateway runtime health / reconnect handling

Proposed Fix (optional)

Possible fixes:

1. Do not mark Slack connected until actual Socket Mode establishment is confirmed
2. Add background task monitoring for _socket_mode_task
3. If _socket_mode_task fails/exits unexpectedly, call _set_fatal_error(...) + _notify_fatal_error() so gateway reconnect / restart logic can take over
4. Optionally add a Slack adapter health check based on the underlying Socket Mode client session/task state

Related Issues

Potentially related, but not duplicates:

• #5499 — Feishu gateway intermittently drops inbound messages, delays reconnects, and may hang on shutdown
• #11163 — Gateway silently drops messages when WebSocket platform adapter is briefly disconnected

Are you willing to submit a PR for this?

• I'd like to fix this myself and submit a PR