[Due for payment 2026-07-29] Receipt captured via long-press shortcut lost — expense saved as $0 with no receipt and no failure feedback

[melvin-bot]

Problem

A user captured a receipt in NewDot using the long-press shortcut to take and upload a receipt. The expense was created but ended up as a $0 expense with no receipt — the receipt image is nowhere to be found, and the user received no feedback that anything had failed.

This is a concrete instance of the failure mode tracked in #92139 (receipt durability + observability when upload fails).

Repro (as reported)

1. In the app, use the long-press shortcut to take a receipt and upload it.
2. Observe the resulting expense.

Expected: The receipt is attached to the expense (or, if the upload fails, the user is clearly notified and given a recovery path).
Actual: The expense is saved as $0 with no receipt attached, and no error/feedback is shown. The receipt image cannot be located.

What we need

1. Traceability — we must be able to trace what happened in cases like this from logs: whether the image was captured, whether the upload was enqueued, whether/when it was sent, and the server response. (Tracks with the observability work in [Due for payment 2026-07-23] Improve receipt durability and observability when upload fails #92139.)
2. User feedback — the user must always receive clear feedback when something fails, instead of silently ending up with a $0, receipt-less expense.

Related

• Parent tracking issue: [Due for payment 2026-07-23] Improve receipt durability and observability when upload fails #92139
• Related PRs: Add receipt capture-to-upload observability logging #94950 (capture-to-upload logging), Save unsent receipts to the device gallery on sign-out #94973 (save unsent receipts to gallery on sign-out)

Reported in Slack.

Issue Owner

Current Issue Owner: @mallenexpensify

[MelvinBot]

Issue Analysis

Root Cause: The "$0 expense with no receipt and no feedback" is the normal optimistic state of a scan expense whose create request was silently dropped before the receipt reached the server. A scan expense is created with a hardcoded amount: 0 and merchant (none) on purpose — SmartScan fills those in server-side later (MoneyRequest.ts:159,202, merchant placeholder CONST/index.ts:2333). So if the create-with-receipt request never completes, the expense is stranded at $0 / (none) / SCANREADY with the receipt gone. There are two silent-drop points that produce exactly this symptom with zero user feedback:

1. Sign-out cancels the in-flight request without writing a failure (most likely for this report). In SequentialQueue.ts:227, a REQUEST_CANCELLED (sign-out) or DUPLICATE_RECORD request is removed from the queue without applying failureData — failureData is only applied inside the shouldFailAllRequests sub-branch. Every other give-up branch in that .catch applies failureData; this one doesn't. So the optimistic $0/SCANREADY transaction stays, the receipt (which only existed inside that request payload) is lost, and no errors field is ever written — which is exactly what would otherwise trigger the receipt-error UI.

2. A non-uploadable receipt is dropped to undefined at the API layer. In TrackExpense.ts:1871: receipt: isFileUploadable(receipt) ? receipt : undefined. isFileUploadable requires a live Blob (web) or an object with a uri (native) — isFileUploadable/index.ts:3. Because Onyx only persists a {source, filename, type} reference — not the blob — any reload/remount/queue-restore between capture and send leaves a bare object that fails this check and is sent as undefined, creating a receipt-less $0 expense with no error.

Only a server-returned failure surfaces feedback today (via getReceiptError → the "Save receipt / Delete expense" UI, MoneyRequestBuilder.ts:326). The two paths above bypass that entirely — hence the silent loss.

Confidence: High on the code mechanism; Medium on which of the two paths caused this specific report — that needs production logs (see below). This aligns with the parent hypothesis in #92139 ("something blocks the write queue between capture and a sign-out").

Recommended Fix:

1. Apply failureData before dropping a cancelled request. In SequentialQueue.ts:227, apply failureData (writing a RECEIPT_ERROR onto the transaction) for REQUEST_CANCELLED too, so the user gets the existing "Save receipt / Delete expense" recovery UI instead of a silent $0. DUPLICATE_RECORD should keep its current behavior.
2. Guard the drop at the API layer. When isFileUploadable(receipt) is false but the transaction is a scan request (TrackExpense.ts:1871), don't silently send undefined — log it and mark the transaction with a receipt error rather than persisting a receipt-less expense.
3. Land the observability in Add receipt capture-to-upload observability logging #94950 and durability in Save unsent receipts to the device gallery on sign-out #94973 (gallery save) so future occurrences are diagnosable and recoverable — this issue is the concrete case those PRs are meant to cover.

Investigation details & verification hints

Why $0 / "(none)": scan create hardcodes amount: 0, merchant: '' → resolved to PARTIAL_TRANSACTION_MERCHANT = '(none)' in TransactionUtils/index.ts:451; receipt starts in SCANREADY (MoneyRequest.ts:142). While scanning, the UI shows "Scanning…" instead of (none); once the request is gone it settles as $0.

Receipt persistence gap: capture stores only a URI reference, not the blob — Receipt.ts setMoneyRequestReceipt. The confirmation page must re-read the blob from that URI via ReceiptFileValidator.tsx; on a non-manual read failure it wipes drafts and bounces to start with no toast (:124, :131-133) — a third, UX-only loss surface.

To confirm which path fired for this report, check logs (PR #94950 adds the relevant lines) for the affected transactionID/request around the reported time:

• [SequentialQueue] Removing persisted request because it failed and doesn't need to be retried. with command: RequestMoney/TrackExpense and errorName: requestCancelled → confirms path 1 (the smoking gun).
• Whether the RequestMoney/TrackExpense write ever reached the server for that transactionID (absent server-side + a cancel log = client-side drop).
• push()/flush() persistence lines → distinguishes cancelled-in-flight from never-persisted (process killed before flush).

Alternatives considered: (a) server-side upload failure — ruled out as the silent case because that path does write a receipt error and surfaces recovery UI; (b) expired blob:// at the confirmation page — plausible on web reload but usually redirects rather than persisting a $0 expense. Both are secondary to the two drop points above.

Note on repo scope: both fix locations are in Expensify/App (SequentialQueue.ts, TrackExpense.ts), so this is fixable within App.

Related (already tracked): parent #92139 (durability + observability), #94950 (capture-to-upload logging), #94973 (save unsent receipts to gallery on sign-out). No separate duplicate found — this is the concrete instance those track.

---

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

[mountiny]

Root cause found (traced from production logs)

I traced jason@expensify.com's specific case in our logs and it is a concrete instance of the failure mode in #92139.

The exact event:

• When: 2026-07-07T11:04:09Z
• Device: iPhone — Expensify/9.4.28.0 CFNetwork/3860.600.12 Darwin/25.5.0
• Command: RequestMoney
• Log: [prepareRequestPayload] Receipt file missing at upload time
• Receipt source: file:///.../Shared/AppGroup/…/sharedFiles/Recibo de CASA MIRLO SL. #BEio.pdf

One clarification vs. the report: jason's receipt was a PDF shared into the app through the iOS Share Extension, not a camera long-press capture. The underlying failure is identical either way, and the same [prepareRequestPayload] Receipt file missing at upload time alert is firing across many iPhone users in the last two weeks (RequestMoney / ReplaceReceipt, with sources in sharedFiles/, Library/Caches/, and Documents/Receipts-Upload/).

Why the receipt is lost and the expense ends up $0

The receipt's local file path is enqueued directly into the write queue, then the file is deleted before the deferred upload actually runs:

1. The iOS Share Extension writes the file to the App Group sharedFiles/ folder (ios/ShareViewController/ShareViewController.swift) and RCTShareActionHandlerModule.m returns that transient path as-is (fileContent = [fileURL absoluteString]) — it is never copied to stable app storage.
2. RequestMoney is enqueued with receipt.source = that transient path and amount: 0.
3. The multipart upload is deferred via the SequentialQueue (offline / backgrounded / behind other writes).
4. The file disappears before upload because: (a) ShareViewController.setupSharedFolder wipes the entire sharedFiles/ folder on the next share, (b) files are written with .completeFileProtection so they're unreadable while the device is locked, or (c) iOS reclaims the App Group temp container.
5. At upload, src/libs/prepareRequestPayload/index.native.ts calls checkFileExists(source), it returns false, so the receipt is silently omitted from the FormData — only a Log.alert is emitted.
6. The server therefore creates a $0 expense with no receipt, and the user gets no feedback.

flowchart TD
    A["Share PDF into Expensify"] --> B["ShareViewController writes to AppGroup/sharedFiles/"]
    B --> C["Native handler returns raw sharedFiles path (no copy)"]
    C --> D["RequestMoney enqueued, receipt.source = transient path, amount 0"]
    D --> E["Upload deferred (offline / background / queued)"]
    E --> F["File gone: next share wipes folder / device locked / OS reclaim"]
    F --> G["checkFileExists=false -> receipt dropped, only Log.alert"]
    G --> H["$0 expense, no receipt, no user feedback"]

Loading

Confirming the two asks in this issue

• Traceability: the only current signal is the server-side Log.alert. The richer capture-to-upload tracing in Add receipt capture-to-upload observability logging #94950 and the gallery-save recovery in Save unsent receipts to the device gallery on sign-out #94973 are still open/unmerged, so neither exists in production yet (no [Receipt] logs in the tree).
• User feedback: prepareRequestPayload drops the receipt without marking the transaction or notifying the user, which is exactly why this ends as a silent $0 expense.

Suggested fixes

1. Durability: copy shared/captured receipts to stable app-owned storage (e.g. Documents/Receipts-Upload) before enqueuing, so a folder wipe / OS cleanup can't destroy a pending receipt.
2. Feedback: when checkFileExists fails at upload time, mark the transaction with a receipt error and surface a user-facing message + recovery path instead of silently creating a $0 receiptless expense.