Summary

Describe the problem and fix in 2–5 bullets:

• Problem: in-process SIGUSR1 restarts could leave old Telegram long-poll internals alive long enough to conflict with the next polling cycle (getUpdates 409 storms).
• Why it matters: overlapping poll loops can cause unstable inbound routing and repeated conflict backoff after config-triggered restart.
• What changed: when a polling cycle exits, monitor teardown now awaits both runner.stop() and bot.stop() before continuing/restarting.
• What did NOT change (scope boundary): no Telegram routing logic changes, no retry-policy changes, and no restart scheduler changes.

Change Type (select all)

• Bug fix
• Feature
• Refactor
• Docs
• Security hardening
• Chore/infra

Scope (select all touched areas)

• Gateway / orchestration
• Skills / tool execution
• Auth / tokens
• Memory / storage
• Integrations
• API / contracts
• UI / DX
• CI/CD / infra

Linked Issue/PR

• Closes Telegram provider leaks polling loop on SIGUSR1/graceful restart #31107

User-visible / Behavior Changes

• Telegram polling restart/teardown is stricter: bot instance is explicitly stopped at polling-cycle exit, reducing post-restart getUpdates conflicts.

Security Impact (required)

• New permissions/capabilities? (No)
• Secrets/tokens handling changed? (No)
• New/changed network calls? (No)
• Command/tool execution surface changed? (No)
• Data access scope changed? (No)
• If any Yes, explain risk + mitigation:

Repro + Verification

Environment

• OS: macOS (dev)
• Runtime/container: Node 22+, pnpm
• Model/provider: n/a
• Integration/channel (if any): Telegram polling monitor
• Relevant config (redacted): n/a

Steps

1. Start Telegram monitor polling loop.
2. Trigger restart/abort path for the polling cycle.
3. Verify bot teardown occurs before next cycle progression.

Expected

• Polling cycle exit always stops both runner and bot instance.

Actual

• Before fix: only runner stop was awaited.
• After fix: runner + bot stop both awaited during polling teardown.

Evidence

Attach at least one:

• Failing test/log before + passing after

• Trace/log snippets

• Screenshot/recording

• Perf numbers (if relevant)

• pnpm test src/telegram/monitor.test.ts

• pnpm check

Human Verification (required)

What you personally verified (not just CI), and how:

• Verified scenarios:
  • Added regression test that monitor teardown calls bot stop() when polling cycle exits.
  • Existing monitor restart tests still pass, including recoverable-error restart behavior.
• Edge cases checked:
  • Teardown keeps fail-safe behavior when stop paths are already completed.
• What you did not verify:
  • Live Telegram Bot API end-to-end on a production token under repeated config.patch restarts.

Compatibility / Migration

• Backward compatible? (Yes)
• Config/env changes? (No)
• Migration needed? (No)
• If yes, exact upgrade steps:

Failure Recovery (if this breaks)

• How to disable/revert this change quickly:
  • Revert this commit.
• Files/config to restore:
  • src/telegram/monitor.ts
  • src/telegram/monitor.test.ts
• Known bad symptoms reviewers should watch for:
  • Telegram polling not restarting after recoverable failures.

Risks and Mitigations

• Risk:
  • Extra teardown step could expose latent bot.stop implementation quirks in edge environments.
  • Mitigation:
    • bot.stop() is wrapped fail-safe and does not crash teardown if already stopped.