Android - Attachment - Error shows up when taking a photo then tapping X

[applause-bot]

If you haven’t already, check out our contributing guidelines for onboarding. To join our Slack channel, fill out this form.

---

Version Number: 9.4.84-0
Reproducible in staging?: Yes
Reproducible in production?: N/A - new feature, doesn't exist in prod
If this was caught during regression testing, add the test name, ID and link from BrowserStack: #96458
Email or phone of affected tester (no customers): osidnjosjdiojisoj@gmail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Mac 26.5 / Chrome
App Component: Chat Report View

Action Performed:

1. Launch Expensify app.
2. Go to workspace chat.
3. Tap + > Add attachment > Take photo.
4. Take a photo, then quickly tap X.

Expected Result:

No error will show up.

Actual Result:

Error shows up when taking a photo then quickly tapping X.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7262820_1789688510633.Screen_Recording_20260918_071856_Expensify.mp4

View all open jobs on GitHub

Applause Internal Information
Exported by: Mita Rachim
Bug ID: 7262820

[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/0ffa7f975501122b1df66a12f1acb2fc96774e5f5367c108b5a122a2d3188fc5

[melvin-bot]

You have been assigned to this deploy blocker because you recently merged this PR: #96458

[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.

[melvin-bot]

@mountiny @robertjchen @huult you have been assigned to this deploy blocker because you reviewed the offending PR: #96458

[melvin-bot]

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

[MelvinBot]

🔍 Investigation Summary

Classification: Frontend bug
Causing PR: fix: use in-app VisionCamera for chat attachment photos (re-land) - by @MelvinBot (High confidence)
Related Issues: [$250] Android - Attachment - App crashes after taking a photo (the crash this PR fixes — relevant to the revert decision)

Recommendation: ROLL FORWARD

The bug is a missing cancellation guard on the error branch of the capture promise — a few-line targeted fix — while reverting would re-introduce the Android 16 crash in [$250] Android - Attachment - App crashes after taking a photo that this PR (a third attempt at landing the feature) exists to fix. Reverting trades a spurious error alert for an app crash, so a forward fix is the better trade.

Assigned: @huult, @robertjchen, @mountiny (approving reviewers of #96458) — already assigned by automation; the PR author is a bot, so no author to add.
Labels: No changes. DeployBlockerCash stays (App-side cause, App-side fix). DeployBlocker was never applied and is not being added — nothing here points at the backend.

📋 Detailed Analysis

Evidence

• The issue is Reproducible in staging: Yes / Production: N/A - new feature. The in-app camera for chat attachments is brand new in 9.4.84-0 and ships entirely in #96458, which replaced the external react-native-image-picker camera intent with an in-app VisionCamera modal (launchCamera/* deleted, AttachmentCamera.tsx added). Before this PR the "Take photo" flow handed off to the OS camera app, so the reported X-button-during-capture path did not exist.
• #96458 merged 2026-09-17T20:24:55Z; this blocker was filed 2026-09-18T01:12Z against the release containing it (it is item 59 in the checklist's chronological list).
• The PR's own QA steps cover "tap the close (X) button" (step 10) but only after the modal is idle — never while a takePhoto() is still in flight, which is exactly the reported sequence.
• The reporter linked the same PR, and the code confirms it rather than merely correlating with it.

Verification

Affected files, both introduced/rewritten by #96458:

• src/components/AttachmentPicker/AttachmentCamera.tsx (new file in this PR)
• src/components/AttachmentPicker/index.native.tsx (camera launch/close wiring)

I checked every other PR in Deploy Checklist: New Expensify 2026-09-17 against these paths: the commit history for both AttachmentCamera.tsx and AttachmentPicker/index.native.tsx on staging consists solely of commits from this PR's branch (claude-inAppCameraAttachments-relandV2). No other PR in this release touches the camera, the attachment picker, or the capture/teardown path.

Root Cause

A cancel-during-capture race, and specifically an asymmetric guard: the success branch checks whether the camera was closed mid-capture, the failure branch does not.

AttachmentCamera.tsx#L161-L190:

.then((photo: PhotoFile) => {
    // Discard capture if the camera was closed while takePhoto was in-flight
    if (!isActiveRef.current) {
        return;
    }
    ...
})
.catch((error: Error) => {
    Alert.alert(translate('receipt.cameraErrorTitle'), translate('receipt.cameraErrorMessage')); // L185 - no isActiveRef guard
    logCameraCaptureFailed(error);
})

Sequence for the reported steps:

1. Tapping the shutter starts takePhoto() (L161-L165).
2. Tapping X runs handleClose L198-L203 → onClose() → handleCameraClose L460-L469, which sets isAttachmentCameraVisible to false.
3. That flows straight into isActive={isVisible} L273 on the VisionCamera, tearing the session down while the capture is still pending. On Android this unbinds the CameraX use cases and aborts the in-flight ImageCapture, so takePhoto() rejects instead of resolving.
4. The rejection lands in the unguarded .catch at L184-L187 and fires a native Alert — which, because the modal has already dismissed, surfaces on top of the chat. That is the error in the video.

onError={handleCameraError} has the same shape — L193-L196 alerts unconditionally — so a session/camera-has-been-disconnected runtime error raised during the same teardown produces an identical alert. Both paths need the fix.

Why Android-only: on iOS, AVFoundation finishes delivering an in-flight photo before the session deactivates, so the promise resolves and the existing isActiveRef guard silently discards it. Android's CameraX aborts it, taking the unguarded .catch.

Suggested targeted fix (in AttachmentCamera.tsx):

• Set isActiveRef.current = false synchronously inside handleClose rather than waiting for the useEffect at L104-L106 to commit, so the guard is already correct when the rejection arrives.
• Apply the same if (!isActiveRef.current) { return; } guard to the .catch and to handleCameraError before alerting (still log to Sentry, just skip the user-facing Alert).

The exact VisionCamera error code should be visible in Sentry for 9.4.84-0 via logCameraCaptureFailed, which would confirm step 3's mechanism from device data; the diagnosis above is from the code paths and the reported repro, not from device logs.

💡 Suggested AI code review rule

This bug looks like a recurring, mechanically detectable pattern, so it may be worth a coding-standards rule so the AI reviewer catches the next one. Proposed for Expensify/App, as an amendment to the existing PERF-15 rule (which today only covers useEffect-initiated async work and only the .then branch, so it does not catch this):

• Rule: amend PERF-15 — "Apply cancellation guards to the failure branch too, and to event-handler promise chains"
• Condition: when a promise chain guards its .then with a mount/visibility flag (isActiveRef, ignore, isMounted), the chained .catch must carry the same guard before any user-visible side effect (Alert.alert, show*Alert, navigation, setState). Applies to chains started from event handlers, not just from useEffect. Logging may stay unguarded.
• Why: cancelling an async native operation (camera capture, upload, picker) rejects the promise, so an unguarded .catch reports the user's own cancellation back to them as an error — here, an error alert on top of the chat after tapping X (#101499).
• Search pattern: \.then\( … isActiveRef\.current|ignore|isMounted … followed by a .catch( in the same chain containing Alert\.alert\(|show[A-Za-z]*Alert\( with no guard. Reviewer grep: rg -U -A6 '\.catch\(' --glob '*.tsx' | rg 'Alert\.alert|showCameraAlert'.
• Offending code (❌): AttachmentCamera.tsx#L166-L187 — guarded .then, unguarded .catch
• Second occurrence (evidence this recurs): IOURequestStepOdometerImage/index.native.tsx#L242-L248 — same takePhoto().catch(... showCameraAlert()) shape with no cancellation guard
• Fix (✅): guard the .catch (and onError) with the same if (!isActiveRef.current) { return; } used on the success path, keeping the Sentry log outside the guard

The full amended rule, with the ❌/✅ code inline in App's coding-standards format, would go in Expensify/App itself. If it's worth adding, a maintainer can open it there as a draft PR.

[huult]

@ShridharGoel Could you take a look at this issue?