slack-bolt 1.27.0 · slack-sdk 3.40.1 · Python 3.11 · AsyncApp + AsyncSocketModeHandler · multiple bots in one workspace.
After idle periods, some apps reconnect Socket Mode ("A new session (...) has been established" is logged) but the normal "Bolt app is running!" line never follows, and from that point inbound events are silently never delivered. Process stays alive, health/memory logs continue — only event dispatch dies. Other identically-deployed bots that emit regular outbound traffic survive the same idle windows, suggesting idle-reconnect handler reattachment as the locus.
Repro pattern (consistent across multiple apps/hosts):
working: connect → auth → new session → "Bolt app is running!" → events flow
failure: idle → old session abandoned → new session established → no "Bolt app is running!" → no events, no errors
Mitigation found: a 60s per-app auth.test keepalive prevents the failure entirely — which works but shouldn't be necessary.
Questions:
- Known issue in 1.27.0 with handler reattachment after idle reconnect?
- Is the missing "Bolt app is running!" after a new session a reliable failure signal we can watchdog on?
- Is this fixed in a newer release?
Happy to provide sanitized reconnect logs.
slack-bolt 1.27.0 · slack-sdk 3.40.1 · Python 3.11 · AsyncApp + AsyncSocketModeHandler · multiple bots in one workspace.
After idle periods, some apps reconnect Socket Mode ("A new session (...) has been established" is logged) but the normal "Bolt app is running!" line never follows, and from that point inbound events are silently never delivered. Process stays alive, health/memory logs continue — only event dispatch dies. Other identically-deployed bots that emit regular outbound traffic survive the same idle windows, suggesting idle-reconnect handler reattachment as the locus.
Repro pattern (consistent across multiple apps/hosts):
Mitigation found: a 60s per-app
auth.testkeepalive prevents the failure entirely — which works but shouldn't be necessary.Questions:
Happy to provide sanitized reconnect logs.