When a Telegram/WhatsApp/iMessage session was viewed or messaged from the
dashboard/webchat, resolveLastChannelRaw() unconditionally returned 'webchat'
for any isDirectSessionKey() or isMainSessionKey() match, overwriting the
persisted external delivery route.
This caused subagent completion events to be delivered to the webchat/dashboard
instead of the original channel (Telegram, WhatsApp, etc.), silently dropping
messages for the channel user.
Fix: only allow webchat to own routing when no external delivery route has been
established (no persisted external lastChannel, no external channel hint in the
session key). If an external route exists, webchat is treated as admin/monitoring
access and must not mutate the delivery route.
Updated/added tests to document the correct behaviour.
Fixes#47745
1. [P1] Treat remap failures as resume failures — if replaceSubagentRunAfterSteer
returns false, do NOT clear abortedLastRun, increment failed count.
2. [P2] Count scan-level exceptions as retryable failures — set result.failed > 0
in the outer catch block so scheduleOrphanRecovery retry logic triggers.
3. [P2] Persist resumed-session dedupe across recovery retries — accept
resumedSessionKeys as a parameter; scheduleOrphanRecovery lifts the Set to
its own scope and passes it through retries.
4. [Greptile] Use typed config accessors instead of raw structural cast for TLS
check in lifecycle.ts.
5. [Greptile] Forward gateway.reload.deferralTimeoutMs to deferGatewayRestartUntilIdle
in scheduleGatewaySigusr1Restart so user-configured value is not silently ignored.
6. [Greptile] Same as #4 — already addressed by the typed config fix.
Co-Authored-By: Devin AI <158243242+devin-ai-integration[bot]@users.noreply.github.com>
Addresses Codex review feedback — if recovery fails (e.g. gateway
still booting), retries up to 3 times with exponential backoff
(5s → 10s → 20s) before giving up.