#12369: fix: register unhandled rejection handler for Slack monitor
channel: slack
stale
Cluster:
Slack Gateway Error Handling
## Summary
- Slack monitor crashes the entire gateway process when a transient network error (ECONNRESET, ETIMEDOUT, etc.) escapes Slack Bolt's internal handling as an unhandled promise rejection
- Telegram (`src/telegram/monitor.ts:97`) and WhatsApp (`src/web/auto-reply/monitor.ts:229`) monitors already register `registerUnhandledRejectionHandler()` to suppress these transient errors gracefully
- This adds the same pattern to the Slack monitor: transient network errors are logged and suppressed instead of crashing
## Test plan
- [x] Follows established pattern from Telegram/WhatsApp monitors
- [x] Handler registered before `app.start()`, cleaned up in `finally` block
- [x] Only suppresses errors matching `isTransientNetworkError()` — all other errors propagate normally
- [x] TypeScript compiles without errors
Closes #12354
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
<!-- greptile_comment -->
<h2>Greptile Overview</h2>
<h3>Greptile Summary</h3>
This change adds an `unhandledRejection` suppression hook to the Slack monitor provider so transient network failures (e.g., `ECONNRESET`, `ETIMEDOUT`) that escape Slack Bolt don’t crash the whole gateway process. It follows the existing cross-channel pattern by registering a handler before `app.start()` and unregistering it in the `finally` cleanup path, while allowing non-transient errors to continue propagating through the global unhandled-rejection handler.
<h3>Confidence Score: 5/5</h3>
- This PR is safe to merge with minimal risk.
- The change is small, localized to the Slack monitor startup/teardown path, and matches the existing unhandled-rejection suppression pattern already used by other monitors. The handler only suppresses well-defined transient network errors and is properly unregistered in the `finally` block; the global `installUnhandledRejectionHandler()` is already installed by the main entrypoint, so this hook will be effective at runtime.
- No files require special attention
<!-- greptile_other_comments_section -->
**Context used:**
- Context from `dashboard` - CLAUDE.md ([source](https://app.greptile.com/review/custom-context?memory=fd949e91-5c3a-4ab5-90a1-cbe184fd6ce8))
- Context from `dashboard` - AGENTS.md ([source](https://app.greptile.com/review/custom-context?memory=0d0c8278-ef8e-4d6c-ab21-f5527e322f13))
<!-- /greptile_comment -->
Most Similar PRs
#17879: fix: prevent Slack auth errors from crashing the entire gateway
by zuyan9 · 2026-02-16
84.6%
#2917: Slack: fix thread context + prevent reply spillover
by SocialNerd42069 · 2026-01-27
77.5%
#7563: fix: expand transient network error detection
by kaigritun · 2026-02-03
76.9%
#23787: Handle transient Slack request errors without crashing the gateway
by graysurf · 2026-02-22
76.8%
#21163: Prevent Slack DNS errors from crashing the gateway
by graysurf · 2026-02-19
76.8%
#19083: Slack: preserve per-thread context and consistent thread replies
by jkimbo · 2026-02-17
76.7%
#7141: fix(telegram): unify network error detection to prevent poll crashes
by hclsys · 2026-02-02
76.6%
#6447: fix(telegram): auto-restart polling when grammY runner exits silently
by AugmentAdvertise · 2026-02-01
75.5%
#6463: fix(telegram): improve timeout handling and prevent channel exits
by ai-fanatic · 2026-02-01
75.4%
#12656: fix: install unhandled rejection handler before async boot operations
by kiranirabatti · 2026-02-09
75.2%