fix: keep shared receipts out of the folder the iOS share extension wipes

[mountiny]

Problem

Two separate things destroy a shared receipt before its expense finishes uploading. The share extension wipes its own folder on every new share, so sharing a second receipt deletes the first one's file while that first request is still queued. The extension also writes files with .completeFileProtection, which makes them unreadable while the device is locked. In either case the request goes out without the receipt and the user gets a $0 expense with no error shown.

Shared receipts drop at 2.05% against a 0.59% iOS baseline — 101 of 4,938 between Aug 8 and Aug 18, 2026.

Solution

SubmitDetailsPage now moves the shared file into Documents/Receipts-Upload before reading it, using the same ReceiptStorage.adopt the camera and gallery paths already use, and points the draft receipt at the moved copy. The receipt therefore lives outside the folder the extension wipes, so a later share cannot delete it and a retry reads the durable copy rather than an emptied path.

ShareViewController drops the .completeFileProtection option so a locked device can still read the file, and checkFileExists logs the stat code so a permission failure stops looking like a deleted file. The protection fix that actually reaches iOS users ships in Mobile-Expensify#14063, because HybridApp builds Mobile-Expensify/iOS/SmartScanExtension; the copy in this PR only keeps the two from diverging.

PR

#98974

Companion iOS extension PR: https://github.com/Expensify/Mobile-Expensify/pull/14063

Issue Owner

Current Issue Owner: @ZhenjaHorbach

[MelvinBot]

Issue Analysis

Confirmed — high confidence. The write-up is accurate on both mechanisms, and the fix in #98974 targets the right layer. I verified each claim against the code.

Root cause (two independent failures, either one produces a $0 expense):

1. Folder wipe. Every incoming share runs setupSharedFolder, which enumerates the entire sharedFiles app-group folder and removeItems every file before saving the new one — ShareViewController.swift:77-86. The native reader hands JS a path pointing into that folder rather than copying the file out (RCTShareActionHandlerModule.m:88), so a second share deletes the first receipt while its offline request is still queued against that now-empty path.

2. File protection. Files are written with .completeFileProtection (ShareViewController.swift:39), which makes them unreadable while the device is locked, so a queue that flushes on a locked phone reads nothing.

Share was the only capture path that read its source directly without adopting it into the durable folder. Camera (IOURequestStepScan/.../Camera/index.native.tsx:168) and gallery (AttachmentPicker/index.native.tsx:141) already call ReceiptStorage.adopt — a move (RNFS.moveFile, deletes the source — ReceiptStorage/index.native.ts:46) into Documents/Receipts-Upload, a folder nothing prunes.

Fix assessment: Correct and minimal.

• Adopting at submit (not ingestion) in SubmitDetailsPage moves the file out of the wiped folder and, because adopt is a move, a retry re-reads the durable copy rather than the emptied shared path — the three added tests cover exactly this (adopt→read, adopt-fail fallback, retry-from-durable).
• The protection change in this repo is inert for shipped iOS — HybridApp builds Mobile-Expensify/iOS/SmartScanExtension, so the fix users actually get is Mobile-Expensify#14063. The App-side edit only keeps the two copies from diverging, as the PR states.

Investigation details & considerations

• Data flow that corrupts the request: share A → folder wiped (empty) → A saved with .completeFileProtection → JS gets a file:// path inside sharedFiles (not copied out) → request queued offline against that path → share B → setupSharedFolder wipes the folder, deleting A → A's queued request flushes against a missing (or, if locked, unreadable) file → $0 expense, no error surfaced.
• adopt fallback: on adopt failure the code logs adoptFailed and falls back to the raw shared path for that session (SubmitDetailsPage change). This degrades gracefully but leaves the original failure modes possible in the rare adopt-failure case — acceptable, since the alternative is blocking the submit entirely.
• checkFileExists telemetry: logging the stat code (e.g. EPERM) is a good observability add — a locked-device permission failure previously looked identical to a deleted file, muddying the drop-rate signal. The code param is correctly whitelisted for Sentry forwarding.
• Root cause is not a regression from an identifiable PR — it's the share extension's long-standing design (wipe-on-share + full file protection), so there's no single offending commit to attribute; a code-review rule wouldn't generalize here.
• Not web-testable: this is entirely an iOS native share-extension / file-protection issue, so it can only be verified on a physical iPhone with a passcode (as the PR's QA steps note).

---

This issue already has a fix PR in review (#98974) plus the companion Mobile-Expensify#14063, so no implementation is needed from me. Reply with @MelvinBot <feedback> to refine this analysis.