fix(whatsapp): add ACK timeout sweep and retry by khaira777 · Pull Request #1384 · FreeOpenSourcePOS/FloCafe

khaira777 · 2026-10-26T20:19:18Z

Intent

Fix #1344 and address Qodo review feedback on PR #1384:

Add ACK timeout sweep (ACK_TIMEOUT_MS = 5 minutes, ACK_SWEEP_INTERVAL_MS = 60 seconds) marking stale outbound 'queued', 'seen', or 'typing' rows as 'failed' with error = 'ack_timeout', while excluding active in-flight sends and starting the ACK timeout window when socket submission finishes.
Sweep unfinished pre-restart / unsubmitted outbound rows on startup in initFromDb() without prematurely sweeping runtime-submitted rows within the 5-minute ACK window.
Allow late server ACKs in messages.update (status 2/3/4) to promote 'failed' rows to 'sent', 'delivered', or 'read', including ACKs referencing prior retry attempt external_message_id values.
Add in-place retry (retryMessage / POST /api/whatsapp/messages/:id/retry and UI Retry button on the Sent tab with localized status toast) that blocks in Offline mode, honours feat: add WhatsApp message templates, automated rules, and safety controls #1315 safety controls, associates recentBodies with messageId after validation passes, and preserves rate-limit tracking on timeout sweep.

What Changed

Add a 5-minute WhatsApp ACK timeout sweep (sweepAckTimeouts, running every 60s while connected, on socket open, during scheduled automation sweeps, and on initFromDb() startup for unfinished pre-restart or unsubmitted rows) that marks non-in-flight outbound queued, seen, or typing rows as failed with error = 'ack_timeout' after refreshing typing_at when socket submission completes.
Update advanceStatus and messages.update handling so late server ACKs (status 2/3/4, including prior retry-attempt external_message_id values) promote failed rows to sent, delivered, or read, clear error and failed_at, backfill earlier status timestamps, and ignore lower-rank out-of-order updates.
Add in-place outbound retry (retryMessage, POST /api/whatsapp/messages/:messageId/retry, and a Sent-tab Retry action in the WhatsApp dashboard) that coalesces concurrent retries, enforces Offline mode and outbound safety controls without self-blocking on the retried row, and documents and tests the timeout, late-ACK, startup-sweep, and retry contracts.

Risk Assessment

✅ Low: The ACK timeout sweep, startup sweep, late ACK promotion, and in-place retry changes are well-bounded, preserve rate-limit and duplicate-body invariants across edge cases, enforce Offline mode and permission checks, and have comprehensive behavioral test coverage.

Testing

Ran the focused WhatsApp service, schema, middleware, RTL, and offline-mode test suites, then stood up an isolated FloCafe server and drove all 7 ACK timeout, startup sweep, late server ACK, and in-place retry scenarios live against the Express API, SQLite database, and Playwright Chromium on the /whatsapp Sent tab, capturing 6 UI screenshots and a full JSON verification transcript.

Live validation: ✅ go - 7 of 7 scenarios driven live against the product

Scenario	Result	Live	Evidence
Outbound message without a server ACK remains in typing inside the 5-minute window and is swept to failed (ack_timeout) after ACK_TIMEOUT_MS while preserving external_message_id and duplicate-body / r…	✅ pass	live	~/.no-mistakes/evidence/01M5X46FX1KZ7AXZAS3Q7WYPPS/01-sent-tab-typing-awaiting-ack.png; ~/.no-mistakes/evidence/01M5X46FX1KZ7AXZAS3Q7WYPPS/02-sent-tab-ack-timeo…
Active in-flight outbound send is excluded from sweepAckTimeouts while socket.sendMessage is pending, and typing_at is refreshed when socket submission finishes so the 5-minute ACK timeout window star…	✅ pass	live	~/.no-mistakes/evidence/01M5X46FX1KZ7AXZAS3Q7WYPPS/whatsapp-ack-timeout-live-verification.json; npm run test:whatsapp-service
Startup initFromDb() sweeps unfinished pre-restart queued and typing outbound rows to failed (ack_timeout) without prematurely sweeping runtime-submitted rows within the 5-minute ACK window	✅ pass	live	~/.no-mistakes/evidence/01M5X46FX1KZ7AXZAS3Q7WYPPS/whatsapp-ack-timeout-live-verification.json; npm run test:whatsapp-service
Late Baileys messages.update server ACKs (status 2/3/4) promote failed rows to sent, delivered, or read (including via a prior retry attempt external_message_id), backfill timestamps via COALESCE, and…	✅ pass	live	~/.no-mistakes/evidence/01M5X46FX1KZ7AXZAS3Q7WYPPS/04-sent-tab-promoted-after-late-ack.png; ~/.no-mistakes/evidence/01M5X46FX1KZ7AXZAS3Q7WYPPS/whatsapp-ack-time…
Staff clicks Retry on a failed outbound row in the WhatsApp Sent tab (POST /api/whatsapp/messages/:id/retry), showing a localized Queued toast and re-sending the message in place without creating dupl…	✅ pass	live	~/.no-mistakes/evidence/01M5X46FX1KZ7AXZAS3Q7WYPPS/03-sent-tab-retry-queued-toast-and-typing-row.png; ~/.no-mistakes/evidence/01M5X46FX1KZ7AXZAS3Q7WYPPS/whatsap…
Retrying a message is blocked in Offline mode (503 offline_mode API, localized Offline mode toast, and disabled Retry button in UI), rejects non-failed rows (400 not_failed), and enforces reports.view…	✅ pass	live	~/.no-mistakes/evidence/01M5X46FX1KZ7AXZAS3Q7WYPPS/05-sent-tab-retry-offline-mode-toast.png; ~/.no-mistakes/evidence/01M5X46FX1KZ7AXZAS3Q7WYPPS/06-sent-tab-retr…
Retrying an outbound message enforces #1315 safety controls (quiet hours, weekly automated cap, and duplicate-body check against other recent messages) while allowing self-retry and not poisoning rece…	✅ pass	live	~/.no-mistakes/evidence/01M5X46FX1KZ7AXZAS3Q7WYPPS/whatsapp-ack-timeout-live-verification.json; npm run test:whatsapp-service

Evidence: Live API, database, and UI verification transcript for all 7 WhatsApp ACK timeout and retry scenarios

{
  "startedAt": "2026-10-26T22:30:25.641Z",
  "scenarios": {
    "scenario1": {
      "msg1Before": {
        "id": 1,
        "phone_e164": "+12133734253",
        "bill_id": 101,
        "customer_id": null,
        "direction": "outbound",
        "kind": "bill_receipt",
        "status": "typing",
        "body": "FloCafe Receipt #BILL-101 ($42.00) - Thank you for visiting!",
        "error": null,
        "queued_at": "2026-10-26 22:30:26",
        "seen_at": null,
        "typing_at": "2026-10-26 22:30:26",
        "sent_at": null,
        "delivered_at": null,
        "read_at": null,
        "failed_at": null,
        "created_by_user_id": "e2e-owner",
        "trigger_rule": null
      },
      "earlySwept": 0,
      "timeoutSwept": 1,
      "msg1AfterSweep": {
        "id": 1,
        "phone_e164": "+12133734253",
        "bill_id": 101,
        "customer_id": null,
        "direction": "outbound",
        "kind": "bill_receipt",
        "status": "failed",
        "body": "FloCafe Receipt #BILL-101 ($42.00) - Thank you for visiting!",
        "error": "ack_timeout",
        "queued_at": "2026-10-26 22:30:26",
        "seen_at": null,
        "typing_at": "2026-10-26 22:30:26",
        "sent_at": null,
        "delivered_at": null,
        "read_at": null,
        "failed_at": "2026-10-26 22:35:32",
        "created_by_user_id": "e2e-owner",
        "trigger_rule": null
      },
      "dupNonRetrySend": {
        "status": 400,
        "data": {
          "error": "Identical message sent to this number recently.",
          "reason": "content_blocked"
        }
      },
      "screenshots": [
        "~/.no-mistakes/evidence/01M5X46FX1KZ7AXZAS3Q7WYPPS/01-sent-tab-typing-awaiting-ack.png",
        "~/.no-mistakes/evidence/01M5X46FX1KZ7AXZAS3Q7WYPPS/02-sent-tab-ack-timeout-failed-with-retry-btn.png"
      ]
    },
    "scenario2": {
      "inFlightMessageId": 2,
      "sweptDuringInFlight": 0,
      "checkDuringInFlight": {
        "status": "typing",
        "error": null
      },
      "swept60sAfterFinish": 0,
      "check60sAfterFinish": {
        "status": "typing",
        "error": null,
        "typing_at": "2026-10-26 22:30:28"
      }
    },
    "scenario3": {
      "afterRuntimeInit": {
        "status": "typing",
        "error": null
      },
      "sweptPreQueued": {
        "status": "failed",
        "error": "ack_timeout",
        "failed_at": "2026-10-26 22:30:28"
      },
      "sweptPreTyping": {
        "status": "failed",
        "error": "ack_timeout",
        "failed_at": "2026-10-26 22:30:28"
      }
    },
    "scenario5": {
      "msg1PreRetry": {
        "id": 1,
        "status": "failed",
        "error": "ack_timeout",
        "external_message_id": "live-ext-1"
      },
      "msg1AfterUiRetry": {
        "id": 1,
        "status": "typing",
        "error": null,
        "failed_at": null,
        "external_message_id": "live-ext-3"
      },
      "totalRowsBeforeUiRetry": 4,
      "totalRowsAfterUiRetry": 4,
      "concurrentRetryResponses": [
        {
          "status": 200,
          "data": {
            "ok": true,
            "messageId": 3
          }
        },
        {
          "status": 200,
          "data": {
            "ok": true,
            "messageId": 3
          }
        }
      ],
      "socketCallsForConcurrent": 1,
      "screenshot": "~/.no-mistakes/evidence/01M5X46FX1KZ7AXZAS3Q7WYPPS/03-sent-tab-retry-queued-toast-and-typing-row.png"
    },
    "scenario4": {
      "msg1PromotedViaPriorExt": {
        "status": "delivered",
        "error": null,
        "failed_at": null,
        "sent_at": "2026-10-26 22:30:29",
        "delivered_at": "2026-10-26 22:30:29"
      },
      "msg1AfterOutOfOrder": {
        "status": "delivered"
      },
      "msg1AfterRead": {
        "status": "read",
        "read_at": "2026-10-26 22:30:29"
      },
      "inFlightPromotedSent": {
        "status": "sent",
        "error": null,
        "failed_at": null,
        "sent_at": "2026-10-26 22:30:29"
      },
      "screenshot": "~/.no-mistakes/evidence/01M5X46FX1KZ7AXZAS3Q7WYPPS/04-sent-tab-promoted-after-late-ack.png"
    },
    "scenario6": {
      "statusInOffline": {
        "enabled": true,
        "state": "disconnected",
        "connectedPhone": "+15550001111",
        "lastError": null,
        "lastErrorReason": null,
        "cooldownUntil": null,
        "offlineMode": true,
        "filterGroups": true
      },
      "apiOfflineRetry": {
        "status": 503,
        "data": {
          "error": "Offline mode is on. Turn it off in Settings to use WhatsApp.",
          "reason": "offline_mode"
        }
      },
      "notFailedRetry": {
        "status": 400,
        "data": {
          "error": "Only failed messages can be retried.",
          "reason": "not_failed",
          "messageId": 1
        }
      },
      "notFoundRetry": {
        "status": 404,
        "data": {
          "error": "Message not found.",
          "reason": "not_found"
        }
      },
      "badIdRetry": {
        "status": 400,
        "data": {
          "error": "messageId must be a positive integer",
          "reason": "not_found"
        }
      },
      "serverZReportRetry": {
        "status": 403,
        "data": {
          "error": "Insufficient permissions",
          "required": "reports.view",
          "code": "PERMISSION_DENIED"
        }
      },
      "ownerZReportRetry": {
        "status": 200,
        "data": {
          "ok": true,
          "messageId": 5
        }
      },
      "screenshot": "~/.no-mistakes/evidence/01M5X46FX1KZ7AXZAS3Q7WYPPS/05-sent-tab-retry-offline-mode-toast.png"
    },
    "scenario7": {
      "quietHoursRetryRes": {
        "status": 400,
        "data": {
          "error": "Automated messages are paused during quiet hours.",
          "reason": "quiet_hours",
          "messageId": 6
        }
      },
      "weeklyCapBlockedRes": {
        "status": 400,
        "data": {
          "error": "Weekly automated message limit reached for this customer.",
          "reason": "weekly_cap",
          "messageId": 6
        }
      },
      "weeklyCapSelfAllowedRes": {
        "status": 200,
        "data": {
          "ok": true,
          "messageId": 6
        }
      },
      "dupOtherRetryRes": {
        "status": 400,
        "data": {
          "error": "Identical message sent to this number recently.",
          "reason": "content_blocked",
          "messageId": 8
        }
      },
      "rejectedUnpaidRetry": {
        "status": 400,
        "data": {
          "error": "Bill is not paid.",
          "reason": "send_failed",
          "messageId": 9
        }
      },
      "validSendAfterUnpaidReject": {
        "status": 200,
        "data": {
          "ok": true,
          "messageId": 10
        }
      }
    }
  },
  "completedAt": "2026-10-26T22:30:33.601Z"
}

Pipeline

Updates from git push no-mistakes

✅ **intent** - passed

✅ No issues found.

✅ **Rebase** - passed

✅ No issues found.

✅ **Review** - passed

✅ No issues found.

✅ **Test** - passed

✅ No issues found.

Live validation: ✅ go - 7 of 7 scenarios driven live against the product

Scenario	Result	Live	Evidence
Outbound message without a server ACK remains in typing inside the 5-minute window and is swept to failed (ack_timeout) after ACK_TIMEOUT_MS while preserving external_message_id and duplicate-body / r…	✅ pass	live	~/.no-mistakes/evidence/01M5X46FX1KZ7AXZAS3Q7WYPPS/01-sent-tab-typing-awaiting-ack.png; ~/.no-mistakes/evidence/01M5X46FX1KZ7AXZAS3Q7WYPPS/02-sent-tab-ack-timeo…
Active in-flight outbound send is excluded from sweepAckTimeouts while socket.sendMessage is pending, and typing_at is refreshed when socket submission finishes so the 5-minute ACK timeout window star…	✅ pass	live	~/.no-mistakes/evidence/01M5X46FX1KZ7AXZAS3Q7WYPPS/whatsapp-ack-timeout-live-verification.json; npm run test:whatsapp-service
Startup initFromDb() sweeps unfinished pre-restart queued and typing outbound rows to failed (ack_timeout) without prematurely sweeping runtime-submitted rows within the 5-minute ACK window	✅ pass	live	~/.no-mistakes/evidence/01M5X46FX1KZ7AXZAS3Q7WYPPS/whatsapp-ack-timeout-live-verification.json; npm run test:whatsapp-service
Late Baileys messages.update server ACKs (status 2/3/4) promote failed rows to sent, delivered, or read (including via a prior retry attempt external_message_id), backfill timestamps via COALESCE, and…	✅ pass	live	~/.no-mistakes/evidence/01M5X46FX1KZ7AXZAS3Q7WYPPS/04-sent-tab-promoted-after-late-ack.png; ~/.no-mistakes/evidence/01M5X46FX1KZ7AXZAS3Q7WYPPS/whatsapp-ack-time…
Staff clicks Retry on a failed outbound row in the WhatsApp Sent tab (POST /api/whatsapp/messages/:id/retry), showing a localized Queued toast and re-sending the message in place without creating dupl…	✅ pass	live	~/.no-mistakes/evidence/01M5X46FX1KZ7AXZAS3Q7WYPPS/03-sent-tab-retry-queued-toast-and-typing-row.png; ~/.no-mistakes/evidence/01M5X46FX1KZ7AXZAS3Q7WYPPS/whatsap…
Retrying a message is blocked in Offline mode (503 offline_mode API, localized Offline mode toast, and disabled Retry button in UI), rejects non-failed rows (400 not_failed), and enforces reports.view…	✅ pass	live	~/.no-mistakes/evidence/01M5X46FX1KZ7AXZAS3Q7WYPPS/05-sent-tab-retry-offline-mode-toast.png; ~/.no-mistakes/evidence/01M5X46FX1KZ7AXZAS3Q7WYPPS/06-sent-tab-retr…
Retrying an outbound message enforces #1315 safety controls (quiet hours, weekly automated cap, and duplicate-body check against other recent messages) while allowing self-retry and not poisoning rece…	✅ pass	live	~/.no-mistakes/evidence/01M5X46FX1KZ7AXZAS3Q7WYPPS/whatsapp-ack-timeout-live-verification.json; npm run test:whatsapp-service

npm run test:whatsapp-service
npm run test:whatsapp-schema
npm run test:whatsapp-middleware
npm run test:rtl-kds-server-whatsapp
npm run test:offline-mode
Live FloCafe server + Playwright Chromium verification on /whatsapp Sent tab and /api/whatsapp/* (whatsapp-ack-timeout-live-verification.json)

✅ **Document** - passed

✅ No issues found.

✅ **Lint** - passed

✅ No issues found.

✅ **Push** - passed

✅ No issues found.

coderabbitai · 2026-10-26T20:19:27Z

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

Run configuration

Source mode: Auto
Repository: FreeOpenSourcePOS/FloCafe
Branch: fm/flocafe-1344-whatsapp-ack-timeout-scout
File: .coderabbit.yaml
Commit: 139c469
Layers: Repository YAML
Review profile: CHILL
Plan: Advanced
Run ID: daa45417-2dd7-4e8c-a05c-d7534360a336

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

🔍 Trigger review

Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

_{Comment @coderabbitai help to get the list of available commands.}

qodo-code-review · 2026-10-26T20:20:02Z

PR Summary by Qodo

Fix WhatsApp messages stuck sending with ACK timeout and retry

🐞 Bug fix ✨ Enhancement 🧪 Tests 📝 Documentation 🕐 40+ Minutes

AI Description

• Fail outbound messages left awaiting an ACK, while accepting late and out-of-order ACKs.
• Retry failed messages in place through a protected API and Sent-tab action.
• Cover timeout and retry behavior with isolated tests, and document the new workflow.

Diagram

graph TD
  A["Sent tab"] --> B["Retry API"] --> C{"Safety passed?"} --> D["Message row"] --> E["WhatsApp socket"] --> F["ACK handler"]
  G["Timeout sweep"] -->|mark failed| D
  F -->|promote status| D
  D -->|refresh| A

High-Level Assessment

The following are alternative approaches to this PR:

1. Create a new row for each retry

➕ Preserves a separate record of every send attempt.
➖ Requires grouping attempts in message history and complicates duplicate prevention and ACK attribution.

2. Schedule a timer per pending message

➕ Could detect timeouts closer to the five-minute threshold.
➖ Adds timer lifecycle and restart-recovery complexity for each message.

Recommendation: Keep the periodic sweep and in-place retry: they fit the existing message-history model and make concurrent retries easier to coalesce. If per-attempt audit history becomes a requirement, add a separate attempt record rather than duplicating message rows.

Files changed (6) +882 / -45

Enhancement (2) +139 / -4

page.tsxOffer retry for failed Sent-tab messages +68/-2

Offer retry for failed Sent-tab messages
• Adds a retry action with loading and availability states, maps retry errors to feedback, and polls sent messages so status changes appear without a manual refresh.
frontend/src/app/(dashboard)/whatsapp/page.tsx

whatsapp.tsExpose a permission-checked message retry route +71/-2

Expose a permission-checked message retry route

• Adds the retry endpoint with outbound-row lookup, report permission checks, request tracking, and reason-based HTTP responses. Existing send routes now return 503 for Offline mode.

main/routes/whatsapp.ts

Bug fix (1) +428 / -41

whatsapp.tsRecover timed-out sends and retry failed rows in place +428/-41

Recover timed-out sends and retry failed rows in place

• Adds startup and periodic ACK timeout sweeps, late-ACK status promotion, and coalesced retries that reset an existing failed row. Retries retain sending safeguards, exclude their own row from relevant limits, and respect Offline mode.

main/services/whatsapp.ts

Tests (1) +302 / -0

whatsapp-service.test.tsCover ACK timeout, late ACK, and retry behavior +302/-0

Cover ACK timeout, late ACK, and retry behavior

• Adds mocked-socket regression cases for timeout boundaries, startup recovery, late and out-of-order ACKs, Offline mode, quiet hours, and concurrent in-place retries without duplicate sends.

tests/whatsapp-service.test.ts

Documentation (2) +13 / -0

cloud-integrations.mdDocument WhatsApp ACK recovery and retry +12/-0

Document WhatsApp ACK recovery and retry
• Explains when pending messages time out, how late ACKs restore status, and how retries reuse a row while enforcing safety controls.
docs/architecture/cloud-integrations.md

api.mdDocument the message retry endpoint +1/-0

Document the message retry endpoint
• Adds the retry route, its permissions, and its key success and error responses to the WhatsApp API reference.
docs/reference/api.md

qodo-code-review · 2026-10-26T20:22:36Z

Code Review by Qodo

🐞 Bugs (1) 📘 Rule violations (0) 🔗 Cross-repo conflicts (0) 📜 Skill insights (0)

1. ~~A slow send can be sent twice~~ ✓ Resolved

Description

sweepAckTimeouts() marks an old typing row failed without checking whether its original send is
still in flight. When that send takes longer than five minutes, a retry can wait on its recipient
lock, then requeue and transmit the same row after the original send completes.

Code

main/services/whatsapp.ts[R899-902]

+          UPDATE whatsapp_messages
+          SET status = 'failed', error = 'ack_timeout', failed_at = ?
+          WHERE id = ? AND direction = 'outbound' AND status IN ('queued', 'seen', 'typing')
+            AND datetime(COALESCE(typing_at, seen_at, queued_at)) <= datetime(?)

Relevance

●●● Strong
Timeout sweep races asynchronous sends, enabling duplicate transmission; closely matches accepted
WhatsApp lifecycle-race fixes.
PR-#1306

ⓘ Recommendations generated based on similar findings in past PRs

Evidence
The sweep selects rows solely by status and transition time. The send remains in typing across
asynchronous socket operations, while retry uses the same per-recipient lock and requires only that
the row still be failed when it acquires that lock.
main/services/whatsapp.ts[881-916]
main/services/whatsapp.ts[2038-2073]
main/services/whatsapp.ts[1711-1721]
main/services/whatsapp.ts[1798-1814]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
A send still running at the timeout can be marked failed and retried after its original transmission succeeds.
## Fix Focus Areas
- main/services/whatsapp.ts[872-916]
- main/services/whatsapp.ts[1963-2000]
- main/services/whatsapp.ts[2038-2073]
## Recommended Fix
Track which message IDs have an active send and exclude them from the ACK sweep until the send attempt completes. Start the ACK timeout when submission finishes, then allow retry only after that attempt is no longer active.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

2. ~~Late delivery receipts vanish after retry~~ ✓ Resolved

Description

The retry update sets external_message_id to NULL before the new attempt has an ID, discarding
the only stored link to the first submission. If an ACK for that submission arrives during or after
retry, findMessageByExternalId() cannot find the row, so its delivery status is never recorded.

Code

main/services/whatsapp.ts[1977]
+            external_message_id = NULL,

Relevance

●●● Strong
Nulling the only external ID breaks late-ACK correlation, directly undermining the PR’s late-ACK
recovery intent.
PR-#1306

ⓘ Recommendations generated based on similar findings in past PRs

Evidence
ACK lookup searches only the current external_message_id. Retry clears that column, and the new ID
is not stored until the later socket.sendMessage call returns.
main/services/whatsapp.ts[1963-1991]
main/services/whatsapp.ts[924-929]
main/services/whatsapp.ts[1110-1132]
main/services/whatsapp.ts[2065-2073]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
Retry discards the original external message ID, making late ACKs for the first attempt unmatchable.
## Fix Focus Areas
- main/services/whatsapp.ts[1963-2000]
- main/services/whatsapp.ts[924-929]
- main/services/whatsapp.ts[1110-1132]
## Recommended Fix
Persist external IDs for prior attempts, for example in an attempt-to-row mapping, and resolve ACKs through that mapping. Define how an ACK from an earlier attempt updates a row while a newer attempt is underway.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

3. ~~Retries can repeat another recent send~~ ✓ Resolved

Description

sendMessageInternal() skips isDuplicateBody() entirely for retries and calls
recordRecentBody() instead. If an older failed row is retried after a separate message with the
same body was recently sent to that phone, the retry bypasses the duplicate-body safety check that
would reject a new send.

Code

main/services/whatsapp.ts[R1909-1910]

+  if (req.retryMessageId == null) {
+    if (isDuplicateBody(req.phoneE164, req.body)) {

Relevance

●●● Strong
Retry bypasses a duplicate-send safeguard for other messages, contradicting the PR’s stated
safety-control intent.
PR-#1014

ⓘ Recommendations generated based on similar findings in past PRs

Evidence
Normal sends consult the per-phone recent-body cache and reject matches. The new retry branch does
not consult it, even when its matching entry came from another message.
main/services/whatsapp.ts[629-658]
main/services/whatsapp.ts[1909-1919]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
Retry bypasses duplicate-body protection for messages other than the retried row.
## Fix Focus Areas
- main/services/whatsapp.ts[629-658]
- main/services/whatsapp.ts[1909-1919]
## Recommended Fix
Make duplicate tracking identify its source message or attempt. Exclude only the retried message's own prior entry when checking a retry, and continue rejecting matching bodies from other recent sends.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

4. ~~A rejected retry blocks a later send~~ ✓ Resolved

Description

sendMessageInternal() records a retry's body in recentBodies before completing bill and
milestone validation. If the retry is rejected because its bill is no longer paid, a subsequent new
message with the same body and phone is treated as a duplicate despite no retry being sent.

Code

main/services/whatsapp.ts[R1917-1918]
+  } else {
+    recordRecentBody(req.phoneE164, req.body);

Relevance

●●● Strong
Retry records duplicate state before validation, so rejected retries poison later sends;
validation-order fixes are accepted precedent.
PR-#1014

ⓘ Recommendations generated based on similar findings in past PRs

Evidence
The new retry branch inserts the body into the cache before the unpaid-bill return. Later normal
sends check that cache and return content_blocked on a matching body.
main/services/whatsapp.ts[629-658]
main/services/whatsapp.ts[1909-1932]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
A rejected retry leaves a recent-body entry that blocks a later send.
## Fix Focus Areas
- main/services/whatsapp.ts[1909-1919]
- main/services/whatsapp.ts[1921-1959]
- main/services/whatsapp.ts[1963-2020]
## Recommended Fix
Move retry body recording until the checks that can reject the attempt have passed, and remove its entry if submission subsequently fails before a message is sent.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

5. ~~Timed-out messages lose duplicate-send protection~~ ✓ Resolved

Description

sweepAckTimeouts() calls clearRecentSendTracking() for a failed row, removing its body from
recentBodies and unconditionally deleting the phone’s lastSendByPhone timestamp, even if that
timestamp belongs to a newer send. When an ACK is lost despite delivery, an ordinary non-retry send
can repeat the body within the 10-minute window; if an older row times out after a newer send, the
next send also bypasses the newer send’s 30-second minimum gap.

Code

main/services/whatsapp.ts[R910-913]

+        if (result.changes > 0) {
+          count += result.changes;
+          clearRecentSendTracking(row.phone_e164, row.body);
+        }

Relevance

●●● Strong
Clearing shared duplicate and rate-limit state can invalidate newer sends; accepted safety fixes
prioritize preserving state integrity.
PR-#1014
PR-#1306

ⓘ Recommendations generated based on similar findings in past PRs

Evidence
clearRecentSendTracking removes the body from recentBodies and deletes the phone’s sole
lastSendByPhone entry, which a newer successful send may have overwritten and the minimum-gap
check reads. The retry path at lines 1909-1919 does not call isDuplicateBody, so clearing this
state is unnecessary for retries and instead disables duplicate-body and minimum-gap protections for
ordinary sends.
main/services/whatsapp.ts[660-668]
main/services/whatsapp.ts[1909-1919]
main/services/whatsapp.ts[631-648]
main/services/whatsapp.ts[683-690]
main/services/whatsapp.ts[904-913]
main/services/whatsapp.ts[2074-2082]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The ACK timeout sweep removes duplicate-body tracking and a per-phone latest-send timestamp when a row times out. An ACK may be lost after delivery, and an older row’s timeout may also erase the timestamp for a newer send.

## Fix Focus Areas
- main/services/whatsapp.ts[660-668]
- main/services/whatsapp.ts[904-916]
- main/services/whatsapp.ts[2074-2082]

## Recommended Fix
Remove the `clearRecentSendTracking(row.phone_e164, row.body)` call from the sweep loop: retries already bypass `isDuplicateBody`, and leaving the tracking intact preserves protection for ordinary sends, including the latest timestamp set by a newer message. If nothing else uses `clearRecentSendTracking`, delete it; if the sweep no longer needs `phone_e164` and `body`, drop them from its SELECT.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

View medium (1)

6. Turning Offline mode off fails messages sent seconds ago 🐞 Bug ≡ Correctness

Description

initFromDb() sets includeAllUnfinished when the socket is null and no send locks remain, causing
sweepAckTimeouts to skip its five-minute cutoff for outbound rows awaiting an ACK. This happens
both on startup and when Offline mode is turned off after suspendForOfflineMode() clears the
socket, so a message submitted moments earlier can be marked failed/ack_timeout and offered for
retry even if it was delivered.

Code

main/services/whatsapp.ts[3172]

+  sweepAckTimeouts(Date.now(), { includeAllUnfinished: !state.socket && sendLocks.size === 0 });

Relevance

●●● Strong
Unconditional startup sweep can fail fresh messages; accepted Offline-mode lifecycle fixes support
guarding asynchronous state transitions.
PR-#1306

ⓘ Recommendations generated based on similar findings in past PRs

Evidence
The settings route calls whatsapp.initFromDb() when Offline mode is switched off, after
suspendForOfflineMode() sets the socket to null; sendMessageWithLock also clears its send lock
after a send finishes. Those conditions enable includeAllUnfinished, whose sweep query has no age
condition. The send path can leave a submitted message unfinished while recording its external ID,
and retryMessage accepts failed rows, so the same premature timeout can occur on startup or
through the Offline-mode-off path and make a possibly delivered message retryable.
main/routes/settings.ts[1734-1744]
main/services/whatsapp.ts[1525-1544]
main/services/whatsapp.ts[1783-1786]
main/services/whatsapp.ts[860-916]
main/services/whatsapp.ts[3160-3174]
main/services/whatsapp.ts[872-909]
main/services/whatsapp.ts[2065-2073]
main/services/whatsapp.ts[1661-1689]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`initFromDb()` can mark recently submitted messages awaiting an ACK as `ack_timeout` and retryable because `includeAllUnfinished` bypasses the age cutoff. This affects both process startup and the runtime path that turns Offline mode off.

## Fix Focus Areas
- main/services/whatsapp.ts[872-903]
- main/services/whatsapp.ts[3160-3177]
- main/routes/settings.ts[1740-1744]

## Recommended Fix
Apply the normal ACK age cutoff to submitted messages on every `initFromDb()` call, including startup and the Offline-mode-off path. If startup requires unconditional cleanup, limit it to rows known to have been interrupted before submission; distinguish the first process-start call from later initialization with a module-level flag or an explicit startup option rather than inferring startup from socket and lock state.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Dismiss ↗ | View ↗

7. ~~Retry success says a receipt was sent~~ ✓ Resolved

Description

retrySentMessage shows tSend('success'), which reads "Receipt sent via WhatsApp.", for every
kind of retried row (manual replies, follow-ups, Z-reports). A successful retry also only means the
message was handed to the socket; the ACK is still pending. Staff get a toast that misnames the
message and overstates delivery, even though the row may time out again.

Code

frontend/src/app/(dashboard)/whatsapp/page.tsx[R509-511]

+      await api.post(`/whatsapp/messages/${messageId}/retry`);
+      toast.success(tSend('success'));
+      await refreshSent();

Relevance

●●● Strong
Success toast is receipt-specific and overstates delivery; correcting the message is a deterministic
UX fix.
ⓘ Recommendations generated based on similar findings in past PRs

Evidence
The whatsapp.send.success translation is receipt-specific. sendMessageInternal returns `ok:
true straight after socket.sendMessage`, without waiting for the ACK.
frontend/src/lib/i18n/messages/en.json[3408-3418]
main/services/whatsapp.ts[2068-2086]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The retry action reuses the receipt-specific success message, and it claims the message was sent when it has only been queued for sending.

## Fix Focus Areas
- frontend/src/app/(dashboard)/whatsapp/page.tsx[509-511]
- frontend/src/lib/i18n/messages/en.json[3408-3418]

## Recommended Fix
Add a key such as `whatsapp.sent.retryQueued` ("Message re-queued for sending.") to every locale file, and use it in `retrySentMessage` in place of `tSend('success')`.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Context sources

⚠️ Tickets: not configured — No jira, linear integration is connected for the linked tickets

✅ Compliance rules (platform): 5 rules

✅ Cross-repo context — repo relationships

Review mode: Auto: 🧠 Deep: Dense cross-layer retry, timeout, concurrency, safety, and status logic across multiple paths.

Tip of the day

💡 Did you know, you can type 'qodo, fix this' on a finding and the fix lands right on your PR

More tips ↗ | Customize Qodo ↗ | Qodo docs ↗

Fixes #1344

…g in api reference

…ontracts

khaira777 requested review from carvalab and itsbkm as code owners October 26, 2026 20:19

qodo-code-review Bot reviewed Oct 26, 2026

View reviewed changes

khaira777 added 4 commits October 26, 2026 18:09

fix(whatsapp): add ACK timeout sweep and retry

589b578

Fixes #1344

no-mistakes(document): docs(whatsapp): trim unrelated table formattin…

bce0d74

…g in api reference

fix(whatsapp): harden ACK timeout sweep and retry edge cases

d08aa84

no-mistakes(document): docs: clarify WhatsApp ACK timeout and retry c…

3383828

…ontracts

khaira777 force-pushed the fm/flocafe-1344-whatsapp-ack-timeout-scout branch from 56e0615 to 3383828 Compare October 26, 2026 22:34

khaira777 changed the title ~~fix(whatsapp): add ACK timeout sweep and retry~~ fix(whatsapp): add ACK timeout sweep and in-place message retry Oct 26, 2026

khaira777 changed the title ~~fix(whatsapp): add ACK timeout sweep and in-place message retry~~ fix(whatsapp): add ACK timeout sweep and retry Oct 26, 2026

Merge branch 'main' into fm/flocafe-1344-whatsapp-ack-timeout-scout

139c469

khaira777 enabled auto-merge (squash) October 26, 2026 22:46

khaira777 merged commit 74f50fb into main Oct 26, 2026
23 checks passed

khaira777 deleted the fm/flocafe-1344-whatsapp-ack-timeout-scout branch October 26, 2026 22:56

This was referenced Oct 29, 2026

fix(whatsapp): persist attempt IDs and lock tail #1399

Merged

feat(reports): WhatsApp sales and auto Z report #1407

Merged

feat(orders): scheduled orders and kitchen release #1408

Merged

Navigation Menu

Repository navigation

fix(whatsapp): add ACK timeout sweep and retry - #1384

fix(whatsapp): add ACK timeout sweep and retry#1384
khaira777 merged 5 commits into
mainfrom
fm/flocafe-1344-whatsapp-ack-timeout-scout

khaira777 commented Oct 26, 2026 •

edited

Loading

Uh oh!

coderabbitai Bot commented Oct 26, 2026 •

edited

Loading

Review skipped

Uh oh!

qodo-code-review Bot commented Oct 26, 2026

Uh oh!

qodo-code-review Bot commented Oct 26, 2026 •

edited

Loading

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

Conversation

khaira777 commented Oct 26, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Intent

What Changed

Risk Assessment

Testing

Pipeline

Uh oh!

coderabbitai Bot commented Oct 26, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Review skipped

Uh oh!

qodo-code-review Bot commented Oct 26, 2026

PR Summary by Qodo

Uh oh!

qodo-code-review Bot commented Oct 26, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Code Review by Qodo

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

khaira777 commented Oct 26, 2026 •

edited

Loading

coderabbitai Bot commented Oct 26, 2026 •

edited

Loading

qodo-code-review Bot commented Oct 26, 2026 •

edited

Loading