Skip to content

[codex] retry whatsapp session init conflicts#101106

Merged
mcaxtr merged 1 commit into
openclaw:mainfrom
andersonjeccel:codex/whatsapp-retry-session-init-conflict
Jul 7, 2026
Merged

[codex] retry whatsapp session init conflicts#101106
mcaxtr merged 1 commit into
openclaw:mainfrom
andersonjeccel:codex/whatsapp-retry-session-init-conflict

Conversation

@andersonjeccel

@andersonjeccel andersonjeccel commented Jul 6, 2026 •
edited
Loading

Copy link
Copy Markdown
Contributor

What Problem This Solves

WhatsApp inbound handling already has a retry path through WhatsAppRetryableInboundError, but reply session initialization conflicted for ... was thrown as a plain error from the native reply session setup path.

When that happened, WhatsApp finalized the inbound delivery as complete even though the agent turn did not run successfully. That committed dedupe state and completed durable receive state, so a later WhatsApp redelivery with the same message id could be ignored instead of retried.

This PR classifies that native session-init conflict as retryable for WhatsApp inbound delivery. The existing WhatsApp dedupe and durable receive retry path then releases the message instead of marking it complete.

Summary

  • classify WhatsApp reply session initialization conflicted inbound failures as retryable delivery failures
  • release WhatsApp inbound dedupe/durable receive state for that native session-init conflict instead of completing the message as delivered
  • add coverage proving a redelivered WhatsApp message with the same id is processed after the conflict and only marked read after the successful retry

Evidence

  • Focused regression proof:
    • node scripts/run-vitest.mjs run --config test/vitest/vitest.extension-whatsapp.config.ts extensions/whatsapp/src/monitor-inbox.streams-inbound-messages.test-support.ts -t "reply session initialization conflicts"
    • result: 1 test passed, 45 skipped
  • Type-check proof:
    • node scripts/run-tsgo.mjs -p test/tsconfig/tsconfig.extensions.test.json --incremental --tsBuildInfoFile .artifacts/tsgo-cache/extensions-test.tsbuildinfo
    • result: passed
  • Full touched WhatsApp inbox test file:
    • node scripts/run-vitest.mjs run --config test/vitest/vitest.extension-whatsapp.config.ts extensions/whatsapp/src/monitor-inbox.streams-inbound-messages.test-support.ts
    • result: 46 tests passed

The new test first throws reply session initialization conflicted for agent:main:whatsapp:direct:+15551234567, confirms WhatsApp does not mark the failed inbound as read, redelivers the same message id, and confirms the second delivery is processed and then marked read.

Notes

This mirrors the retry classification already used by Slack for the same native reply session initialization conflict text, while keeping WhatsApp on its existing dedupe and durable receive retry path.

@openclaw-barnacle openclaw-barnacle Bot added channel: whatsapp-web Channel integration: whatsapp-web size: S triage: needs-pr-context Candidate: external PR body lacks required problem context or evidence. and removed triage: needs-pr-context Candidate: external PR body lacks required problem context or evidence. labels Jul 6, 2026
@clawsweeper

clawsweeper Bot commented Jul 6, 2026 •
edited
Loading

Copy link
Copy Markdown
Contributor

Codex review: needs real behavior proof before merge. Reviewed July 6, 2026, 9:58 PM ET / 01:58 UTC.

Summary
The branch adds a WhatsApp-local retryable-error classifier for reply session initialization conflicted failures and a regression test for same-message-id redelivery before read marking.

PR surface: Source +54. Total +54 across 2 files.

Reproducibility: yes. at source/test level, not as a live reproduction: current main only releases exact WhatsAppRetryableInboundError instances, and the PR's regression test models redelivery after the native conflict string. I did not inspect a real WhatsApp run against current main or the PR head.

Review metrics: 2 noteworthy metrics.

  • Retry classifier surface: 1 added. One new message-pattern classifier now changes whether WhatsApp inbound failures commit or release delivery state.
  • Redelivery regression: 1 added. The new test covers same-message-id redelivery and delayed read receipt, which is the delivery invariant that needs real proof before merge.

Merge readiness
Overall: 🦪 silver shellfish
Proof: 🦪 silver shellfish
Patch quality: 🐚 platinum hermit
Result: blocked until real behavior proof from a real setup is added.

Overall follows the weaker of proof and patch quality, so missing proof can cap an otherwise strong patch.

Rank-up moves:

  • [P1] Add redacted real WhatsApp evidence showing first delivery failure, same-message-id redelivery, delayed read marking, and exactly one successful reply.
  • Update the PR body with that proof so ClawSweeper can re-review automatically; if it does not, ask a maintainer to comment @clawsweeper re-review.

Proof guidance:

  • [P1] Needs real behavior proof before merge: The PR body provides focused Vitest/typecheck output only; it still needs redacted real WhatsApp logs, terminal output, recording, or transcript proving after-fix redelivery behavior before merge. After adding proof, update the PR body; ClawSweeper should re-review automatically. If it does not, the PR author or someone with repository write access can comment @clawsweeper re-review.

Risk before merge

  • [P1] No redacted live WhatsApp proof shows that a real failed delivery is redelivered with the same message id, read marking is delayed, and only one successful reply is sent.
  • [P1] The diff changes WhatsApp dedupe and durable receive finalization for a native error string; if real WhatsApp redelivery differs from the mock, merging could cause repeated retries or duplicate eventual replies.

Maintainer options:

  1. Require live WhatsApp proof (recommended)
    Ask for redacted live WhatsApp logs, terminal output, or a recording showing the conflict, same-id redelivery, delayed read mark, and one successful retry before merge.
  2. Accept mocked proof risk
    Maintainers can intentionally merge based on focused regression coverage and Slack precedent, while owning the risk that real WhatsApp redelivery behavior differs.
  3. Pause this channel patch
    Pause the PR if maintainers want the broader reply-session conflict release path to finish before channel-specific retry classifiers land.

Next step before merge

  • [P1] No automated repair is indicated because there are no concrete code findings; the blocker is contributor-supplied real WhatsApp behavior proof and maintainer proof-sufficiency review.

Maintainer decision needed

  • Question: Should this PR wait for live WhatsApp redelivery proof, or may maintainers accept the mocked regression proof for this message-delivery change?
  • Rationale: The patch is a plausible narrow fix, but it changes message finalization semantics and the available evidence is only unit/typecheck output rather than a real WhatsApp redelivery run.
  • Likely owner: mcaxtr — mcaxtr has recent merged WhatsApp inbound/reconnect history and moved this PR back to ready-for-review.
  • Options:
    • Require live WhatsApp proof (recommended): Ask for redacted live WhatsApp logs, terminal output, or a recording showing the conflict, same-id redelivery, delayed read mark, and one successful retry before merge.
    • Accept mocked proof risk: Maintainers can intentionally land based on the regression test and sibling Slack precedent, but would own any WhatsApp platform redelivery drift.
    • Pause behind broader conflict work: If maintainers want channel-specific retry changes sequenced with the broader reply-session conflict package work, pause this PR until that release path is settled.

Security
Cleared: The diff is limited to WhatsApp inbound retry classification and tests; it does not touch secrets, dependency sources, CI, package resolution, or code-execution supply-chain surfaces.

Review details

Best possible solution:

Land the WhatsApp-local retry classifier after redacted real WhatsApp proof confirms release-for-redelivery, delayed read marking, and single successful reply behavior.

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

Yes at source/test level, not as a live reproduction: current main only releases exact WhatsAppRetryableInboundError instances, and the PR's regression test models redelivery after the native conflict string. I did not inspect a real WhatsApp run against current main or the PR head.

Is this the best way to solve the issue?

Yes, this appears to be the best narrow code layer for the WhatsApp delivery consequence: it reuses the existing WhatsApp retryable inbound path and matches the Slack precedent instead of adding a second dedupe mechanism. The remaining gap is real WhatsApp behavior proof, not a different code shape.

AGENTS.md: found and applied where relevant.

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

Label changes

Label justifications:

  • P1: The PR targets an active WhatsApp inbound workflow where session-init conflicts can cause user messages to be treated as delivered without a successful agent turn.
  • merge-risk: 🚨 message-delivery: The patch changes WhatsApp dedupe and durable receive finalization, so an incorrect match or real redelivery mismatch could duplicate, suppress, or repeatedly retry messages.
  • 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 body provides focused Vitest/typecheck output only; it still needs redacted real WhatsApp logs, terminal output, recording, or transcript proving after-fix redelivery behavior before merge. After adding proof, update the PR body; ClawSweeper should re-review automatically. If it does not, the PR author or someone with repository write access can comment @clawsweeper re-review.
Evidence reviewed

PR surface:

Source +54. Total +54 across 2 files.

View PR surface stats
Area Files Added Removed Net
Source 2 57 3 +54
Tests 0 0 0 0
Docs 0 0 0 0
Config 0 0 0 0
Generated 0 0 0 0
Other 0 0 0 0
Total 2 57 3 +54

What I checked:

  • Current WhatsApp finalization only handles explicit retry errors: Current main releases dedupe and durable receive state only when the thrown error is already a WhatsAppRetryableInboundError; plain native session-init conflict errors fall through to completion/read marking. (extensions/whatsapp/src/inbound/monitor.ts:468, f3106057e62b)
  • Existing WhatsApp retry machinery supports the intended path: The adjacent current test already proves redelivery after an explicit WhatsAppRetryableInboundError, so the PR routes the new conflict string into an established retry path rather than adding a second delivery mechanism. (extensions/whatsapp/src/monitor-inbox.streams-inbound-messages.test-support.ts:1568, f3106057e62b)
  • Sibling Slack precedent exists: Slack already treats the same reply session initialization conflicted string as retryable by scanning the error graph before retrying inbound delivery. (extensions/slack/src/monitor/message-handler.ts:69, f3106057e62b)
  • PR diff matches the described narrow fix: The PR adds a WhatsApp classifier using collectErrorGraphCandidates/formatErrorMessage and changes finalization to release dedupe/durable state for that resolved retryable error, plus the redelivery/read-receipt regression test. (extensions/whatsapp/src/inbound/monitor.ts:105, 3910969037fb)
  • Proof remains mocked/unit-level only: The PR body lists Vitest and tsgo output, the prior ClawSweeper comment asked for redacted real WhatsApp proof, and the ready-for-review event added no new comment or review evidence showing a live WhatsApp redelivery path. (3910969037fb)
  • Related issue context is adjacent, not a close reason: The closed package-parity tracker verifies the broader conflict family in v2026.7.1-beta.2, while open search still shows separate channel-level retry work for Signal; no merged WhatsApp-specific replacement supersedes this PR.

Likely related people:

  • vincentkoc: Authored the merged WhatsApp explicit inbound retry commit and the sibling Slack retry classifier that this PR mirrors. (role: introduced retry behavior; confidence: high; commits: d70e6b13d7e1, c73e80b5a78d; files: extensions/whatsapp/src/inbound/monitor.ts, extensions/whatsapp/src/inbound/dedupe.ts, extensions/slack/src/monitor/message-handler.ts)
  • mcaxtr: Authored merged WhatsApp reconnect and multi-account inbound-state fixes touching the same monitor and reply handoff surface, and marked this PR ready for review. (role: adjacent WhatsApp owner; confidence: medium; commits: da1da6110209, 458a52610a4d; files: extensions/whatsapp/src/inbound/monitor.ts)
What the crustacean ranks mean
  • 🦀 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.

How this review workflow works
  • 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.
Review history (1 earlier review cycle)
  • reviewed 2026-07-06T19:47:07.792Z sha 3910969 :: needs real behavior proof before merge. :: none

@clawsweeper clawsweeper Bot added rating: 🦪 silver shellfish Thin PR readiness signal; proof, validation, or implementation needs work. status: 📣 needs proof The PR needs real behavior proof before ClawSweeper can clear the contributor ask. P1 High-priority user-facing bug, regression, or broken workflow. merge-risk: 🚨 message-delivery 🚨 May drop, duplicate, misroute, suppress, or wrongly target messages. labels Jul 6, 2026
@clawsweeper clawsweeper Bot mentioned this pull request Jul 6, 2026
Closed
@mcaxtr
mcaxtr marked this pull request as ready for review July 7, 2026 01:41
@mcaxtr
mcaxtr merged commit 87a9e27 into openclaw:main Jul 7, 2026
196 of 205 checks passed
@mcaxtr

mcaxtr commented Jul 7, 2026

Copy link
Copy Markdown
Member

Merged via squash.

@github-actions github-actions Bot mentioned this pull request Jul 7, 2026
Open
@Haderach-Ram Haderach-Ram mentioned this pull request Jul 7, 2026
Open
github-actions Bot pushed a commit to Desicool/openclaw that referenced this pull request Jul 7, 2026
@andersonjeccel
retry whatsapp session init conflicts (openclaw#101106)
d89ba9a
@andersonjeccel
andersonjeccel deleted the codex/whatsapp-retry-session-init-conflict branch July 7, 2026 11:53
giodl73-repo pushed a commit to giodl73-repo/openclaw that referenced this pull request Jul 8, 2026
@andersonjeccel @giodl73-repo
retry whatsapp session init conflicts (openclaw#101106)
8f59905
This was referenced Jul 11, 2026
Closed
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

channel: whatsapp-web Channel integration: whatsapp-web merge-risk: 🚨 message-delivery 🚨 May drop, duplicate, misroute, suppress, or wrongly target messages. P1 High-priority user-facing bug, regression, or broken workflow. rating: 🦪 silver shellfish Thin PR readiness signal; proof, validation, or implementation needs work. size: S status: 📣 needs proof The PR needs real behavior proof before ClawSweeper can clear the contributor ask.

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

2 participants

@andersonjeccel @mcaxtr