Message, sent online and followed by force killing the app greyed out when go offline

[applause-bot]

If you haven’t already, check out our contributing guidelines for onboarding and email contributors@expensify.com to request to join our Slack channel!

---

Version Number: 9.4.8-0
Reproducible in staging?: Yes
Reproducible in production?: No
If this was caught during regression testing, add the test name, ID and link from BrowserStack: #91734
Email or phone of affected tester (no customers): N/A
Issue reported by: Applause Internal Team
Bug source: Pull Request QA execution
Device used: iPhone 15 iOS 26.5
App Component: Chat Report View

Action Performed:

1. Sign in to ND
2. Open 1:1 chat, send a message
3. Immediately force kill and relaunch the app
4. Open the same chat, go offline

Expected Result:

The message, sent online before force kill, is not displayed greyed out offline

Actual Result:

Message, sent online and followed by force killing the app greyed out when go offline

Workaround:

Unknown

Platforms:

• Android: App
• Android: mWeb Chrome
• iOS: App
• iOS: mWeb Safari
• iOS: mWeb Chrome
• Windows: Chrome
• MacOS: Chrome Safari

Screenshots/Videos

To be added by Applause Leads

View all open jobs on GitHub

bandicam.2026-06-15.21-19-55-595.mp4

Bug7181465_1781544048276.grey_message.mp4

Applause Internal Information
Exported by: Iuliia Herets
Bug ID: 7181465

[applause-bot]

While Applause doesn't embed attachments for this bug, here are the links for quick view:
https://platform.applause.com/services/links/v1/external/e4a1192f505fedb1e2869aefb5a0a78124271899308695a826c2d0bfd4339e2e

[melvin-bot]

@mountiny recently merged #91734, but they are OOO right now, so I'll auto-assign someone else.

[melvin-bot]

Triggered auto assignment to @marcochavezf (DeployBlockerCash), see https://stackoverflowteams.com/c/expensify/questions/9980/ for more details.

[melvin-bot]

💬 A slack conversation has been started in #expensify-open-source

[github-actions]

👋 Friendly reminder that deploy blockers are time-sensitive ⏱ issues! Check out the open `StagingDeployCash` deploy checklist to see the list of PRs included in this release, then work quickly to do one of the following:

1. Identify the pull request that introduced this issue and revert it.
2. Find someone who can quickly fix the issue.
3. Fix the issue yourself.

[MelvinBot]

Proposal

What is the root cause of that problem?

This is a regression from PR #91734 ("SequentialQueue: await Onyx persist before allowing flush").

That PR made SequentialQueue.push() async and now awaits the disk persist of PERSISTED_REQUESTS before firing flush()/the network XHR (SequentialQueue.ts:588). That was intentional — it fixed requests being silently lost on a crash (#92264) — but it widens the window in which the request is durably on disk yet the XHR has not fired.

When you force-kill immediately after sending, the kill now reliably lands in that window:

• The optimistic report action with pendingAction: ADD is written to Onyx (ReportUtils.ts:6139).
• The AddComment request is persisted to disk.
• The XHR/successData (the only thing that clears pendingAction → Report/index.ts:1007-1019) never runs.

On relaunch the persisted request is reloaded from disk and flush() is called, but going offline makes flush() early-return at its isOfflineNetwork() guard (SequentialQueue.ts:315). The request stays queued, pendingAction: ADD is still set, and OfflineWithFeedback greys the message (OfflineWithFeedback.tsx:98-101). There is no boot-time reconciliation that clears a lingering optimistic pendingAction for an action whose request is still queued, and OpenReport only MERGEs server data so it does not clear it either.

Full evidence chain (confidence: high)

1. Send online → addActions builds the optimistic action with pendingAction: ADD and calls API.write('AddComment', …).
2. push() MERGEs the optimistic action into Onyx and awaits savePersistedRequest() before flushing (SequentialQueue.ts:545-605).
3. Force-kill in the await window → request on disk; XHR never fires; successData never clears pendingAction.
4. Relaunch → PersistedRequests subscriber reloads the request and triggers flush() (PersistedRequests.ts:120-175).
5. Go offline → flush()/process() bail at the offline guard → request stranded, pendingAction stays.
6. OfflineWithFeedback: isOffline && pendingAction === ADD → greyed.

Note: this is partly working as designed — the message genuinely has an unsent, queued request, so greying it while offline is arguably correct. It self-heals when the device is back online (the queue flushes, successData clears pendingAction; AddComment is deduped server-side by reportActionID, so no duplicate message). The visible regression vs. production is that pre-#91734 the request was often lost in the crash window, so nothing remained to grey.

What changes do you think we should make in order to solve the problem?

This is a DeployBlockerCash, so the two viable paths are a team decision:

1. Revert PR #91734 — the standard deploy-blocker remediation. ⚠️ This reintroduces the original bug it fixed ([Due for payment 2026-06-22] SequentialQueue: await Onyx persist before allowing flush #92264: requests silently dropped on crash), so it is a trade, not a clean fix.
2. Accept the new behavior and remove the deploy-blocker — the greyed state is a faithful representation of a genuinely queued/unsent request and self-heals on reconnect with no duplicate send. If we go this route, the QA "expected result" should be updated, since the message was not actually confirmed by the server at kill time.

A true code fix (reconciling lingering optimistic pendingActions against the still-queued request, or treating an on-disk-but-resolved request as confirmed) is non-trivial and risky to land under deploy-blocker time pressure — recommend tracking it separately rather than rushing it here.

I'd lean toward option 2 unless QA can reproduce a duplicate message on reconnect or a message that stays greyed while online, either of which would make this a real correctness bug rather than expected pending-state behavior.

What alternative solutions did you explore? (Optional)

N/A

---

Next Steps for Contributor+ team:
To accept: @MelvinBot implement [this](https://github.com/Expensify/App/issues/93611) to create a draft PR.
To refine: @MelvinBot <your feedback>
To reject: Explain why you are rejecting Melvin's proposal.