← Back to PRs

#21956: fix(line): block monitorLineProvider on abort signal to prevent crash-loop (#21908)

by lailoo open 2026-02-20 15:30 View on GitHub →
docs size: S experienced-contributor
## Summary - **Bug**: LINE `monitorLineProvider` returns immediately, causing auto-restart crash-loop. - **Root cause**: `monitorLineProvider()` in `src/line/monitor.ts` is async but returns a `LineProviderMonitor` object immediately after registering the webhook. The gateway framework expects provider functions to block until the abort signal fires (as Telegram/Discord/Slack providers do). - **Fix**: Add `await new Promise` that blocks until the abort signal fires, matching the Slack provider pattern. Fixes #21908 ## Problem `monitorLineProvider()` returns immediately after registering the webhook HTTP route. The gateway's `trackedPromise` chain in `server-channels.ts` interprets this as "provider exited" and triggers auto-restart with exponential backoff: ``` [line] [default] starting LINE provider (Bot Name) [line] [default] auto-restart attempt 1/10 in 5s [line] [default] starting LINE provider (Bot Name) [line] [default] auto-restart attempt 2/10 in 11s ... ``` Other providers (Telegram, Discord, Slack) all block on a long-lived promise or loop until the abort signal fires. LINE was the only provider that returned immediately. ## Changes - `src/line/monitor.ts` — Add `await new Promise<void>` before the return statement that blocks until the abort signal fires (or resolves immediately if already aborted) **Before fix:** ``` monitorLineProvider() resolves in <5ms → framework triggers restart loop ``` **After fix:** ``` monitorLineProvider() blocks until abort signal → framework sees provider as running ``` ## Test plan - [x] New test: monitorLineProvider blocks until abort signal fires - [x] New test: monitorLineProvider resolves immediately when abort signal already aborted - [x] All existing LINE monitor tests pass - [x] Format and lint pass ## Effect on User Experience **Before:** LINE provider enters a crash-loop on startup, cycling through 10 restart attempts with exponential backoff before giving up. Webhook messages are lost during restart windows. **After:** LINE provider stays running until explicitly stopped via abort signal. <!-- greptile_comment --> <h3>Greptile Summary</h3> Fixed LINE provider crash-loop by blocking `monitorLineProvider` on the abort signal until it fires, matching the pattern used by Slack and expected by the gateway framework in `server-channels.ts`. The immediate return was causing the framework to interpret the provider as exited and trigger exponential backoff auto-restart attempts (lines 203-261 in `server-channels.ts`). **Key changes:** - Added `await new Promise<void>` block (lines 318-324) that waits for abort signal before returning - Handles pre-aborted signals correctly with immediate resolution - Added comprehensive lifecycle tests to prevent regression - Updated CHANGELOG with user-facing fix description The implementation exactly mirrors the Slack provider pattern (lines 355-359 in `src/slack/monitor/provider.ts`) and ensures the provider stays "alive" from the framework's perspective. <h3>Confidence Score: 5/5</h3> - This PR is safe to merge with no concerns - The fix is minimal (7 lines), follows the exact pattern used by the Slack provider, includes comprehensive tests that verify both blocking and pre-aborted edge cases, and directly addresses the root cause identified in the gateway framework's auto-restart logic - No files require special attention <sub>Last reviewed commit: 901bc53</sub> <!-- greptile_other_comments_section --> <!-- /greptile_comment -->

Most Similar PRs