Summary

• Problem: WhatsApp linked-device sessions were force-reconnected after 30 minutes with no inbound app messages, even when the socket was otherwise healthy.
• Why it matters: quiet WhatsApp accounts hit noisy 499 reconnect cycles, missed-message windows, and credential-restore churn that looked like transport failure.
• What changed: the extension-local inbound-message silence watchdog is disabled by default; explicit test/runtime tuning can still enable it.
• What did NOT change (scope boundary): no Baileys auth storage, QR login, outbound delivery queue, or Gateway health-monitor policy changed.

Change Type (select all)

• Bug fix
• Feature
• Refactor required for the fix
• 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 [Bug]: WhatsApp channel force-reconnects every 30 minutes on quiet-device sessions #70678
• Related [Bug] WhatsApp 499 reconnection loop: inactivity timer not reset after successful reconnect #62258, WhatsApp watchdog idle counter doesn't reset on reconnect, causing 60s flap loops #54332, WhatsApp watchdog reconnect loop: inactivity timer not reset after reconnect #55246, [Bug]: WhatsApp Baileys: 499 reconnect loop — idle timer not resetting on reconnect #60337, WhatsApp Baileys: idle message timer doesn't reset on reconnect, causing infinite 499 loop #61326, [Bug]: WhatsApp aggressive 30-minute heartbeat causes cascading reconnects every ~60 seconds #55030, [Bug]: WhatsApp gateway flapping — status 499 reconnect cascade with aggressive heartbeat timeout #60378
• Related Add web.messageTimeoutMs for WhatsApp watchdog #63939 and fix: stop treating idle WhatsApp sessions as stale sockets #47513
• This PR fixes a bug or regression

Root Cause (if applicable)

• Root cause: WhatsApp had an extension-local watchdog that used inbound app-message silence as a liveness signal (lastInboundAt ?? startedAt). Quiet linked-device sessions are normal, so this forced unnecessary 499 reconnects.
• Missing detection / guardrail: coverage proved explicit watchdog behavior, but not the production default for a quiet session with no inbound messages.
• Contributing context (if known): Gateway-level channel health has moved toward transport-backed liveness, but WhatsApp still had this older local app-message watchdog path.

Regression Test Plan (if applicable)

• Coverage level that should have caught this:
  • Unit test
  • Seam / integration test
  • End-to-end test
  • Existing coverage already sufficient
• Target test or file: extensions/whatsapp/src/auto-reply.web-auto-reply.connection-and-logging.e2e.test.ts
• Scenario the test should lock in: a quiet linked-device session remains on the same listener after 31 minutes when no explicit watchdog timeout override is set.
• Why this is the smallest reliable guardrail: the bug is the monitor/controller default wiring, not Baileys network behavior.
• Existing test that already covers this (if any): explicit watchdog reconnect tests still cover the opt-in timeout path.
• If no new test is added, why not: N/A

User-visible / Behavior Changes

Quiet WhatsApp sessions no longer reconnect solely due to no inbound app messages. Actual disconnects and Gateway health state still drive recovery.

Diagram (if applicable)

Before:
quiet WhatsApp account -> 30m no inbound messages -> forced 499 reconnect

After:
quiet WhatsApp account -> no inbound messages -> remains connected unless transport/lifecycle closes

Security Impact (required)

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

Repro + Verification

Environment

• OS: macOS local worktree
• Runtime/container: Node 22 / pnpm
• Model/provider: N/A
• Integration/channel (if any): WhatsApp Web
• Relevant config (redacted): default WhatsApp monitor settings

Steps

1. Start WhatsApp monitor with keepAlive enabled and no messageTimeoutMs override.
2. Leave the linked-device session quiet for longer than 30 minutes.
3. Observe whether a forced 499 reconnect is triggered solely by app-message silence.

Expected

• No forced reconnect occurs from app-message silence alone.

Actual

• Before this PR, the default 30-minute silence watchdog closed the connection with status 499.

Evidence

• Failing test/log before + passing after
• Trace/log snippets
• Screenshot/recording
• Perf numbers (if relevant)

Human Verification (required)

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

• Verified scenarios: pnpm test extensions/whatsapp/src/auto-reply.web-auto-reply.connection-and-logging.e2e.test.ts extensions/whatsapp/src/connection-controller.test.ts
• Edge cases checked: default quiet-session behavior, explicit watchdog override still covered by existing reconnect tests, formatting/whitespace.
• What you did not verify: pnpm check:changed; multiple other worktrees already had check:changed / test lanes running, so I avoided queuing another heavy gate.

Review Conversations

• I replied to or resolved every bot review conversation I addressed in this PR.
• I left unresolved only the conversations that still need reviewer or maintainer judgment.

Compatibility / Migration

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

Risks and Mitigations

• Risk: a genuinely stale but still-open WhatsApp socket may not be restarted by app-message silence alone.
  • Mitigation: reconnect still follows actual socket close/error paths, and Gateway health should use transport/lifecycle signals rather than ordinary inbound app messages.