Greptile Summary

This PR fixes a deterministic false-positive reconnect loop affecting low-traffic WhatsApp accounts by removing two places where "inbox quiet" was incorrectly treated as "socket dead." The fix is conservative and well-scoped: it skips the stale-socket heuristic for WhatsApp at the gateway layer and makes the channel-layer no-message watchdog opt-in (defaulting to Number.POSITIVE_INFINITY instead of 30 minutes). Real disconnect/close handling is untouched. Both layers receive regression test coverage.

• channel-health-policy.ts: Added policy.channelId !== "whatsapp" alongside the existing Telegram exclusion; the updated comment correctly documents that lastEventAt tracks inbound message flow, not socket liveness.
• monitor.ts: MESSAGE_TIMEOUT_MS default changed from 30 * 60 * 1000 to Number.POSITIVE_INFINITY; the watchdog interval is still created but always short-circuits when the timeout is Infinity (minor overhead). The > 30 condition that gates minutesSinceLastMessage in the heartbeat logData is a leftover from the now-removed warn branch and is slightly inconsistent with the new "idle is normal" semantics — see inline comment.
• Tests: New unit tests in both policy/monitor test files, and a new e2e test that drives ~60 000 fake-timer watchdog ticks with no reconnect, correctly exercising the new default.

Confidence Score: 4/5

• Safe to merge; the fix is narrowly scoped and real disconnect/close handling is preserved.
• The root cause analysis is sound and the two-layer fix is correct. No logic bugs found. The only nit is a leftover > 30 threshold in heartbeat logData that was tied to the removed warn-level log — it doesn't affect runtime behavior, just log observability.
• No files require special attention; the style suggestion in extensions/whatsapp/src/auto-reply/monitor.ts is optional cleanup.

This is a comment left during a code review.
Path: extensions/whatsapp/src/auto-reply/monitor.ts
Line: 285-288

Comment:
**Leftover `> 30` threshold in `logData` no longer meaningful**

The `minutesSinceLastMessage` field is only injected into the structured log entry when it exceeds 30 minutes. That threshold was purpose-built to accompany the warn-level log that this PR removes. Now that long idle periods are expected and normal, the `> 30` guard suppresses the field from the heartbeat log for "somewhat quiet" sessions (0–30 m silence) while surfacing it only for "very quiet" ones (> 30 m). Given the semantic shift — idle is now routine — it would be more consistent to include the field whenever a message has been received at all (i.e. when `minutesSinceLastMessage` is non-null), so operators always get the timing signal.

```suggestion
        ...(minutesSinceLastMessage !== null
          ? { minutesSinceLastMessage }
          : {}),
```

How can I resolve this? If you propose a fix, please make it concise.

_{Last reviewed commit: 5709858}

Updated this PR branch to current origin/main and pushed a fresh head to rerun CI on top of the latest baseline.

Local verification before push:

• npx vitest run extensions/telegram/src/bot-message-context.topic-agentid.test.ts
• npx vitest run src/gateway/channel-health-policy.test.ts src/gateway/channel-health-monitor.test.ts

This matters because the prior failing test:channels run was still red on an older base due a Telegram topic-agentId failure outside the WhatsApp stale-socket scope. That test now passes locally on the refreshed branch.

I’ll watch the rerun and only keep patching if the updated branch still shows failures that look specific to this PR.

Thanks for the PR and for working on this. We checked the current main branch, and this fix is already in main via #60007, which landed in commit ff62705.

The WhatsApp watchdog now resets lastInboundAt to null on each reconnect and uses the connection start time as the baseline, so quiet channels no longer enter a tight reconnect loop from stale message timestamps carried across connection runs.

Because that has landed, I'm closing this PR as superseded by #60007.

Thanks again for the work here. If you think this closure is mistaken and your PR still fixes something meaningfully different on current main, feel free to open a new PR with that explanation.