[Due for payment 2026-06-24] [$250] Compose box - Offline attachment disappears after app relaunch before sync

[jponikarchuk]

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.3.66-1
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught during regression testing, add the test name, ID and link from BrowserStack: https://test-management.browserstack.com/projects/2219752/test-runs/TR-24947/folder/13176710/41236949/1387586391?sort=-status_id
Email or phone of affected tester (no customers): casluyo@gmail.com
Issue reported by: Applause Internal Team
Bug source: Regression TC Execution
Device used: samsung s25/ android 16
App Component: Other

Action Performed:

1. Login into the App with a new account
2. Disable internet connection on the device.
3. Navigate to a chat and upload an attachment (image).
4. Verify that the image preview appears immediately in the chat.
5. Close/force-kill the app while still offline.
6. Reopen the app and then enable internet connection (refresh if needed).

Expected Result:

The attachment should remain visible in the chat after reopening the app offline, and once the device goes online it should sync and appear normally (without reduced opacity).

Actual Result:

The attachment uploaded while offline disappears after closing and reopening the app. It does not sync or appear once the internet connection is restored.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Video.mp4

View all open jobs on GitHub

Issue Owner

Current Issue Owner: @ZhenjaHorbach

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022051370070235891983
• Upwork Job ID: 2051370070235891983
• Last Price Increase: 2026-05-11

[MelvinBot]

Proposal

What is the root cause of that problem?

When a user picks an attachment in a chat while offline, the native AttachmentPicker copies the file to cachesDirectory — a temporary directory that Android can purge at any time (especially on force-kill). The API write request containing this file reference is queued in PersistedRequests and persisted to Onyx.

After the app is force-killed:

1. The cache file is deleted by the OS.
2. On relaunch, the SequentialQueue replays the persisted request.
3. prepareRequestPayload tries to read the file from the now-invalid URI — since the chat attachment FileObject typically lacks a source property, it falls through to appending the raw (stale) value to FormData, causing a silent upload failure.

Receipt/expense uploads don't have this bug because they call moveReceiptToDurableStorage to move the file to DownloadDir/Receipts-Upload (a durable directory) before queuing — but chat attachments never do this.

Additionally, if the request is already being processed when force-killed, shouldPersistOngoingRequest skips persisting it entirely because it contains a File/Blob object, so the request is lost completely.

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

Before the chat attachment upload request is queued in the SequentialQueue, move the file from cachesDirectory to durable storage using moveReceiptToDurableStorage (or a similar mechanism). This should happen in the attachment upload flow in addActions (or the caller that prepares the file), so the file URI in the persisted request points to a location that survives app restarts. The source property should also be set on the FileObject so prepareRequestPayload can re-read it correctly on replay.

What alternative solutions did you explore? (Optional)

1. Use the existing cacheAttachment display cache (Documents/attachments) as a fallback source for upload. This was rejected because the display cache serves a different purpose and mixing concerns would be fragile.
2. Detect and clean up stale persisted requests on startup. This would prevent silent failures but wouldn't actually fix the lost-attachment problem — the file would still be gone.

---

Next Steps for Contributor+ team: Reply with @MelvinBot implement this to create a draft PR, @MelvinBot <your feedback> to refine this analysis, or explain why you are rejecting Melvin's proposal.

[melvin-bot]

Triggered auto assignment to Contributor-plus team member for initial proposal review - @ZhenjaHorbach (External)

[Abdulloh0109]

Proposal

What is the root cause of that problem?

The optimistic attachment is destroyed by a chain of three independent issues that all converge on Android force-kill:

1. cacheAttachment is fire-and-forget at src/libs/actions/Report/index.ts:707. The native implementation (src/libs/actions/Attachment/index.native.ts:12-32) does an async RNFS.copyFile(uri, destPath) to the long-lived ${RNFS.DocumentDirectoryPath}/attachments/{attachmentID}.{ext} and only THEN writes COLLECTION.ATTACHMENT{attachmentID} to Onyx. Because addActions does not await it, a force-kill within the few hundred milliseconds before the copy finishes leaves no cached file and no Onyx record.

2. The optimistic HTML embeds the volatile picker URI directly. getUploadingAttachmentHtml at src/libs/ReportUtils.ts:6308-6320 writes <img src="${file.uri}" ...> and data-expensify-source="${file.uri}" straight from the picker. On Android the picker returns a transient content://... URI scoped to the picker process; once the app is killed the URI is revoked, so on relaunch the persisted optimistic action in REPORT_ACTIONS references a source the OS no longer resolves — the image renders as broken/empty even though the action row exists.

3. The persisted ADD_ATTACHMENT request loses its file across the kill. PersistedRequests.save() (src/libs/actions/PersistedRequests.ts:225) calls Onyx.set(PERSISTED_REQUESTS, requests) for the queued request whose data.file is a non-serializable RN file blob. The same module already acknowledges this exact serialization problem at lines 376-381 — but ONLY for ongoingRequest; the comment "These requests cannot survive a crash anyway since File references are lost on restart" is never enforced for the queued (non-ongoing) case. After restart, data.file is hydrated as {} (or as an object whose uri points at a revoked content:// URI). When the network returns and SequentialQueue.flush() processes the request, the multipart upload goes out without a usable file: depending on server tolerance the server either fails the request (failureData decorates the action with an error but does not remove it) or accepts a comment-only payload and successData strips pendingAction/isOptimisticAction, leaving a message with no image — i.e. the attachment is "gone" once online.

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

Two minimal, narrowly scoped edits, both in src/libs/actions/Report/index.ts inside addActions (the file-attachment branch at lines 701-708):

1. Await the cache copy before building anything that depends on the URI. Make addActions (or just its file branch) async/await the cacheAttachment call at line 707. This both (a) guarantees the durable file at ${RNFS.DocumentDirectoryPath}/attachments/{attachmentID}.{ext} exists before the optimistic action is committed to Onyx, and (b) gives us a stable path to use in the next step.

2. Rewrite the URI used by the optimistic action and the persisted request to the cached path. After cacheAttachment resolves, read the freshly written COLLECTION.ATTACHMENT{attachmentID} source (or compute the same destPath locally — ${RNFS.DocumentDirectoryPath}/attachments/{attachmentID}.{ext}) and:

   • Pass {...file, uri: cachedPath} to buildOptimisticAddCommentReportAction at line 705 so getUploadingAttachmentHtml embeds the long-lived path instead of the volatile picker URI. The <img src="file:///data/.../attachments/{id}.jpg"> stays valid across restarts.
   • Pass the same rewritten file (with uri: cachedPath) into parameters.file at line 791 so that when the request is persisted by PersistedRequests.save and later replayed by the queue after restart, the multipart upload reads from a real, app-private file rather than from a revoked content URI or a serialized {} object.

3. Web parity check (no change needed): the web cacheAttachment (src/libs/actions/Attachment/index.ts:10) is not affected because web uses object URLs that survive only inside the same JS runtime; force-kill = full reload there too, but the issue is reproduced only on Android per the report. No edit to the web file is needed.

This keeps the change confined to one function, reuses the existing cacheAttachment infrastructure already in place, and does not require any change to the persisted-request schema or to PersistedRequests.ts.

What alternative solutions did you explore?

• Extending the hasNonSerializableData guard (PersistedRequests.ts:376) to save() so non-serializable requests are dropped before persistence: rejected. That would silently delete the queued ADD_ATTACHMENT request on disk, making the failure even more invisible — the queue would have no record to retry, the optimistic action would hang forever in pendingAction=ADD, and the user would see an undismissable ghost message instead of "the image disappeared."
• Re-uploading from the optimistic ReportAction's HTML on restart by parsing the data-expensify-source attribute and re-fetching: rejected. The picker content:// URI is already revoked at this point; the only durable copy is the one we should have written via cacheAttachment in the first place. Fixing the source of truth (await the copy, rewrite the URI) is strictly less work and has no schema impact.
• Making the entire addActions function synchronous and skipping the cache for offline: rejected. The cache is exactly what makes the offline preview possible — skipping it would regress the "image preview appears immediately" expectation in step 4 of the repro.

[melvin-bot]

Job added to Upwork: https://www.upwork.com/jobs/~022051370070235891983

[neerajbachani]

🚨 Edited by proposal-police: This proposal was edited at 2026-05-04 18:44:03 UTC.

Proposal

What is the root cause of that problem?

On Android, chat attachments are created in a temporary cache path (cachesDirectory) by the picker flow.
When the app is force-killed while still offline, that temporary file may not survive process restart.

Two things then break together:

1. The optimistic report action still references the old temporary URI, so the attachment preview disappears after relaunch.
2. The queued offline upload can also replay with a stale file reference (or missing source path), so the request cannot reliably rebuild multipart payload when network returns.

So this is a file-lifecycle mismatch: we queue offline work using a non-durable file location.

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

Use a durability-first upload path for chat attachments (native only), and keep display cache separate.

1. Normalize attachment before queuing request

   • In the chat attachment send flow, if file is local/offline, move it from temp cache to a durable app-owned upload staging path.
   • If move succeeds, set:
     • file.uri = durableUri (for optimistic rendering),
     • file.source = durableUri (for offline replay in prepareRequestPayload).
   • If move fails, keep current URI as fallback and log a warning.

2. Use normalized file everywhere in the same flow

   • Build optimistic attachment HTML from normalized file (uri now durable).
   • Send API write payload with normalized file (source present for replay).

3. Keep responsibilities separated

   • upload staging = reliability for request replay (all MIME types).
   • cacheAttachment = rendering/cache optimization only (do not depend on it for upload durability).

4. Add cleanup lifecycle

   • Remove staged upload file after terminal outcome (success or non-retriable failure), to avoid stale file growth.

5. Regression coverage

   • Android offline: attach image -> force-kill -> relaunch offline -> reconnect -> attachment remains visible and syncs.
   • Same scenario with a non-image file (e.g., PDF) to verify MIME-agnostic durability.
   • Multi-attachment path (first with text + remaining attachments) to ensure all files follow same normalization.

What alternative solutions did you explore? (Optional)

1. Rely only on existing cacheAttachment

   • Rejected: it is display-oriented and file-type constrained, so it is not a reliable upload source for all attachment types.

2. Drop/clean persisted requests on startup when file is invalid

   • Rejected: prevents silent retries but loses user data and does not solve root durability issue.

3. Patch optimistic preview only

   • Rejected: UI may look fixed, but upload replay can still fail without durable source.

4. Reuse receipt-specific durable logic directly

   • Partially viable, but rejected as-is: receipt path has different lifecycle assumptions. Better to apply the same durability principle via a chat-attachment staging path with clear cleanup ownership.

[github-actions]

⚠️ @neerajbachani Your proposal is a duplicate of an already existing proposal and has been automatically withdrawn to prevent spam. Please review the existing proposals before submitting a new one.

[oqildev]

🚫 Duplicated proposal withdrawn by 🤖 ProposalPolice.

[github-actions]

⚠️ @oqildev Your proposal is a duplicate of an already existing proposal and has been automatically withdrawn to prevent spam. Please review the existing proposals before submitting a new one.