chat-Attaching specific pdf file shows error.

[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: V9.3.99
Reproducible in staging?: Yes
Reproducible in production?: No
If this was caught during regression testing, add the test name, ID and link from BrowserStack: H
Email or phone of affected tester (no customers): dreamnitethedragon+vegst@gmail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Redmi note 10s android 13
App Component: Chat Report View

Action Performed:

1. Launch app
2. Open self dm
3. Attach below pdf file

Expected Result:

Attaching specific pdf file must not show error.

Actual Result:

Attaching specific pdf file shows error.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7171466_1780571412698.Screenrecorder-2026-06-04-16-35-14-453.mp4

Bug7171466_1780571433653!International_Money_Transfer__Send_Money_Abroad_with_Wise__ex-TransferWise___1_ (1).pdf

View all open jobs on GitHub

Applause Internal Information
Exported by: Svetlana Lazutkina
Bug ID: 7171466

Issue Owner

Current Issue Owner: @mkhutornyi

[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/4b1ac3af1a365e2c1a7bcf8694b4f6161812e4c71ad16f223194290cbeb2285c

https://platform.applause.com/services/links/v1/external/dbdcbfc95c2be01eb17221f726ee59dab132bc100158d4c17961a0afab0813db

[melvin-bot]

Triggered auto assignment to @deetergp (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

Confidence: Medium-High. This is a staging-only regression (prod: No, staging: Yes). The release timing points squarely at the react-native-nitro-fetch rollout. The exact byte-level failure lives inside the third-party native client, so the final mechanism for this specific PDF should be confirmed with a device log — but the regression vector is clear enough to act on as a deploy blocker.

What is the root cause of that problem?

Release 9.3.99 enabled react-native-nitro-fetch, which replaces the global fetch/Response/Request/Headers on native (src/polyfills/NitroFetch.ts, imported unconditionally at index.js:5). Every API request — including the attachment upload — now flows through Nitro's native HTTP client at HttpUtils.ts:112, where the PDF is sent as a File/Blob inside a FormData body (fetchParams typed against nitroFetch, L92-L103).

Because most files upload fine and only a specific PDF errors, the failure is an edge case in how Nitro serializes that particular file into the multipart body (most likely its source URI scheme — content:// from the Android SAF picker vs file:// — its size, or its MIME), not a property of the PDF format itself.

Why we're confident it's this and not a pre-existing PDF bug:

• Not reproducible in production → it's new code, not PDF parsing/password/size logic (all unchanged from prod).
• nitro-fetch is the only PR on this release that touches the native network/file plumbing.
• It is unstable: it was first merged as [No QA] feat: Enable react-native-nitro-fetch #92258, reverted, then re-merged as feat: Enable react-native-nitro-fetch #92365 (2026-06-03) — both are on the 9.3.99-1 checklist (Deploy Checklist: New Expensify 2026-06-04 #92626). Prior production release 9.3.98-3 did not include it.

Investigation details & ruled-out paths

• Validation is not the trigger. validateAttachmentFile.ts does not hit fetch for a picked PDF: it returns early on missing size, and the corruption check only runs for images. normalizeFileObject's internal fetch (FileUtils.ts:715-737) is skipped because picker files already have size (the 'size' in file guard) — and even if it ran, NitroFetch.ts routes local schemes back to the original fetch.
• PDF preview is not the trigger. react-native-pdf renders natively and doesn't use JS fetch, so nitro-fetch can't affect the thumbnail/preview.
• ⇒ By elimination, a nitro-fetch regression surfaces at the http(s) upload of the attachment, which is exactly the path in HttpUtils.ts:112.
• There is no runtime flag — the polyfill is applied on import at index.js:5.

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

As a time-sensitive deploy blocker, the safest unblock is to revert the nitro-fetch enablement (#92365) so native uploads fall back to React Native's default networking, then re-test the specific PDF on Android. Since there is no feature flag, reverting is the only off switch today — a flag/guard around the NitroFetch.ts import would make future rollouts safer.

For the real fix, the nitro-fetch author (mkhutornyi) should reproduce with the failing PDF and inspect how Nitro builds the multipart body for that file (URI scheme / size / MIME), since the defect is in the native client rather than App's JS.

What alternative solutions did you explore? (Optional)

Confirm before/instead of reverting by capturing a device log from the Applause repro device (Redmi Note 10s, Android 13, tester dreamnitethedragon+vegst@gmail.com) at the moment of attach — look for a nitro-fetch/Cronet exception or a failed POST /api upload. That pins which property of the "specific" PDF breaks Nitro's serialization.

---

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

[m-natarajan]

Xiaomi Redmi Note 10 / Android 12
v9.3.99-4
Not repro

Screenrecorder-2026-06-04-20-02-57-484.mp4