Best possible solution:

Keep the transport-owned marker change and regression, replace the broad closing reference with a non-closing partial-fix link, and add redacted credentialed WhatsApp restart evidence showing the queued message is delivered exactly once after the real listener connects.

Do we have a high-confidence way to reproduce the issue?

Yes for the WhatsApp subproblem from source with high confidence: the active-listener gate occurs before every platform send, while current main throws an unmarked generic error that durable recovery cannot safely classify as unsent. No credentialed current-main restart was run.

Is this the best way to solve the issue?

Yes for the WhatsApp behavior: using the existing public pre-dispatch marker at the transport-owned listener gate is narrower and safer than adding delay heuristics or a parallel retry queue. It is not a complete resolution of the linked cross-channel issue.

AGENTS.md: found and applied where relevant.

Codex review notes: model internal, reasoning high; reviewed against 90e465833b30.

Label changes:

• add P1: The PR addresses a restart recovery path that can suppress queued WhatsApp messages for real users.
• add merge-risk: 🚨 message-delivery: The changed pre-dispatch classification determines whether durable recovery retries, loses, or duplicates a queued message.
• add rating: 🦪 silver shellfish: Overall readiness is 🦪 silver shellfish; proof is 🦪 silver shellfish and patch quality is 🐚 platinum hermit.
• add status: 📣 needs proof: The PR needs real behavior proof before ClawSweeper can clear the contributor ask. Needs real behavior proof before merge: The PR provides a real-adapter/shared-queue regression and Testbox validation but explicitly lacks a credentialed WhatsApp restart roundtrip; add redacted live output, logs, or a recording, then update the PR body to trigger a fresh review or ask a maintainer to comment @clawsweeper re-review.

Label justifications:

• P1: The PR addresses a restart recovery path that can suppress queued WhatsApp messages for real users.
• merge-risk: 🚨 message-delivery: The changed pre-dispatch classification determines whether durable recovery retries, loses, or duplicates a queued message.
• rating: 🦪 silver shellfish: Overall readiness is 🦪 silver shellfish; proof is 🦪 silver shellfish and patch quality is 🐚 platinum hermit.
• status: 📣 needs proof: The PR needs real behavior proof before ClawSweeper can clear the contributor ask. Needs real behavior proof before merge: The PR provides a real-adapter/shared-queue regression and Testbox validation but explicitly lacks a credentialed WhatsApp restart roundtrip; add redacted live output, logs, or a recording, then update the PR body to trigger a fresh review or ask a maintainer to comment @clawsweeper re-review.

PR surface:

Source +2, Tests +119. Total +121 across 3 files.

What I checked:

• Changed transport gate: The branch throws the public pre-dispatch marker only when no active WhatsApp listener exists, before any listener send method can run. (extensions/whatsapp/src/send.ts:100, c80db1dbcdfc)
• Shared recovery contract: Current main treats PlatformMessageNotDispatchedError as explicit provider proof that no recipient-visible send completed, allowing false attempt evidence to be cleared safely. (src/infra/delivery-recovery.shared.ts:39, 90e465833b30)
• Queue state behavior: The canonical pre-dispatch failure mutation clears platformSendStartedAt and recoveryState together while retaining the queued intent for a later drain. (src/infra/outbound/delivery-queue-storage.ts:158, 90e465833b30)
• Reconnect owner: WhatsApp already owns an account-scoped reconnect drain that bypasses backoff for the no-listener error after connection, so the PR does not add a second retry mechanism. (extensions/whatsapp/src/auto-reply/monitor.ts:546, 90e465833b30)
• Regression coverage: The new test queues through the real WhatsApp adapter and shared durable queue, drains before connect, registers a mocked listener, drains twice, and verifies exactly one recipient send. (extensions/whatsapp/src/send.delivery-recovery.test.ts:80, c80db1dbcdfc)
• Documented plugin API: The channel SDK documentation explicitly directs adapters to use this error when they can prove failure occurred before platform dispatch. Public docs: docs/plugins/sdk-channel-outbound.md. (docs/plugins/sdk-channel-outbound.md:80, 90e465833b30)

Likely related people:

• steipete: Peter is assigned to the canonical issue and is credited in recent merged pre-connect recovery, durable outbound, and WhatsApp reconnect work beyond authoring this proposal. (role: recent recovery-path contributor and issue assignee; confidence: high; commits: 13f8dfae864f, 741d9524bec2, 4c42815348ae; files: src/infra/delivery-recovery.shared.ts, src/infra/outbound/delivery-queue-recovery.ts, extensions/whatsapp/src/auto-reply/monitor.ts)
• SunnyShu0925: Authored the merged change that added retry handling for proven pre-connect failures in the shared durable recovery path. (role: introduced shared pre-connect recovery behavior; confidence: high; commits: 13f8dfae864f; files: src/infra/delivery-recovery.shared.ts, src/infra/outbound/delivery-queue-recovery.ts)
• zhangguiping-xydt: Authored recent merged work preserving outbound recovery send evidence across adapters, directly adjacent to the invariant this PR relies on. (role: recent durable outbound contributor; confidence: high; commits: 741d9524bec2, babc287afe56; files: extensions/whatsapp/src/send.ts, src/infra/delivery-recovery.shared.ts, src/infra/outbound/delivery-queue-recovery.ts)
• VishalJ99: Authored the recent WhatsApp reconnect catch-up change in the monitor path that owns the drain used by this fix. (role: recent WhatsApp reconnect contributor; confidence: high; commits: 4c42815348ae; files: extensions/whatsapp/src/auto-reply/monitor.ts)
• mcaxtr: Recent merged WhatsApp connection, auth, socket, and send-path work makes Marcus a useful adjacent reviewer for live reconnect behavior. (role: recent WhatsApp connection-area contributor; confidence: medium; commits: 6ba19c5ad019, 52d9d16e1be9, 7d8b000bf78a; files: extensions/whatsapp/src/send.ts, extensions/whatsapp/src/auto-reply/monitor.ts, extensions/whatsapp/src/connection-controller.ts)

• 🦀 challenger crab: rare, exceptional readiness with strong proof, clean implementation, and convincing validation.
• 🦞 diamond lobster: very strong readiness with only minor maintainer review expected.
• 🐚 platinum hermit: good normal PR, likely mergeable with ordinary maintainer review.
• 🦐 gold shrimp: useful signal, but proof or patch confidence is still limited.
• 🦪 silver shellfish: thin signal; proof, validation, or implementation needs work.
• 🧂 unranked krab: not merge-ready because proof is missing/unusable or there are serious correctness or safety concerns.
• 🌊 off-meta tidepool: rating does not apply to this item.

Shiny media proof means a screenshot, video, or linked artifact directly shows the changed behavior. Runtime, network, CSP, and security claims still need visible diagnostics.

• ClawSweeper keeps one durable marker-backed review comment per issue or PR.
• Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
• A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
• PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
• Maintainers can also comment @clawsweeper review to request a fresh review only.
• Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
• Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
• Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.