Android - Conversation - Unable to Send Large PDF Files

[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.91-1
Reproducible in staging?: Yes
Reproducible in production?: No
If this was caught during regression testing, add the test name, ID and link from BrowserStack: https://test-management.browserstack.com/projects/2219752/folder/13176710/test-cases/41236946
Email or phone of affected tester (no customers): Sintayewhaylu01@gmail.com
Issue reported by: Applause Internal Team
Bug source: Regression TC Execution
Device used: Samsung A16/ Android 15
App Component: Other

Action Performed:

1. Open the Hybrid app.
2. Open a conversation
3. Send a large PDF file.

Expected Result:

The PDF file should be sent successfully to the conversation.

Actual Result:

The file is not sent, and an error message is displayed in the conversation.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7169477_1780396767991.Recording_20260602_132802.1.mp4

View all open jobs on GitHub

Applause Internal Information
Exported by: Julia Ponikarchuk
Bug ID: 7169477

[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/b725a5fa94d3de0ecdb39c07616025b16e16989adab18881af91f6ac278a3942

[melvin-bot]

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

🤖 This is a regression from #92258 ("[No QA] feat: Enable react-native-nitro-fetch"), merged 2026-06-01 — one day before the v9.3.91 staging deploy. Reverting/disabling it should unblock the deploy. Confidence: High.

Problem: On Android (Hybrid), sending a large PDF in a chat fails — the file is never sent and "Unexpected error posting the comment" appears inline in the conversation. Works in production (9.3.90), broken in staging (9.3.91). Small files and other platforms with bigger heap budgets may not surface it.

What is the root cause of that problem?

#92258 globally swaps the native fetch for react-native-nitro-fetch: index.js:5 imports the polyfill, which sets globalThis.fetch = nitroFetch at src/polyfills/NitroFetch.ts:7. Every App API request now routes through NitroFetch, including the multipart AddAttachment upload at src/libs/HttpUtils.ts:112.

On Android, NitroFetch builds the entire multipart body in memory: its buildMultipartBody() writes into a ByteArrayOutputStream, and readFileBytes() calls readBytes() to load the whole file into a heap ByteArray before handing it to Cronet — no streaming (react-native-nitro-fetch's android/.../NitroFetchClient.kt). For a large PDF inside the Hybrid app (which shares its heap with OldDot), this exhausts memory / throws, the upload fails, and the failed request writes genericAddCommentFailureMessage to the optimistic action (src/libs/actions/Report/index.ts:1035 → "Unexpected error posting the comment", src/languages/en.ts:8283) — the error shown in the conversation.

Why staging-only: the NitroFetch enablement landed after the 9.3.90 production cut, so it's only in 9.3.91. The previous build used React Native's native networking, which streams {uri, name, type} file parts without buffering, so the same PDF uploaded fine. (The PR itself notes it "affect[s] all network requests across the whole app.")

This is not the attachment-validation path — a PDF ≤ 24 MB passes src/libs/validateAttachmentFile.ts cleanly (not a receipt, not HEIC, under the size limit, and PDFs skip the image-corruption check).

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

To unblock the deploy: revert / disable #92258 (remove the import './src/polyfills/NitroFetch' from index.js) so uploads fall back to RN's streaming networking.

Before re-enabling NitroFetch (longer term): make the Android Nitro client stream file parts from the URI instead of buffering the whole file into a ByteArray (fix upstream in react-native-nitro-fetch), or exclude the multipart upload commands (AddAttachment / AddTextAndAttachment / receipt uploads) from the NitroFetch path until streaming is supported.

What alternative solutions did you explore? (Optional)

Send flow traced + alternatives ruled out

• Send path: AttachmentPicker (Android) → validateAttachmentFile (passes) → ReportAddAttachmentModalContent → addAttachmentWithComment → addActions → API.write(ADD_ATTACHMENT, …) → HttpUtils.processHTTPRequest → fetch(url, {body: FormData}) (now NitroFetch on native).
• Ruled out — size-limit change: API_ATTACHMENT_VALIDATIONS.MAX_SIZE (24 MB) is unchanged in this release.
• Ruled out — normalizeFileObject memory read: it early-returns when the file object already has size (the Android document picker always supplies size), so it isn't the trigger here.
• Ruled out — file-path attachment PRs: no App PR in the 9.3.91 deploy touches validateAttachmentFile.ts / FileUtils.ts / the AttachmentModal in the deploy window; the regression is the global fetch swap, which doesn't touch any attachment-named file (easy to miss in a file-path search).
• Related open issue (different symptom, possibly same area): [$250] mWeb-Web page reloads after sending 3 attachments, the attachments are not sent #92108 — "page reloads after sending 3 attachments, attachments not sent" (mWeb/Web). Likely unrelated to this Android/large-file OOM but worth a glance.

Logs that would confirm: Sentry/LogBox OutOfMemoryError from NitroFetchClient / buildMultipartBody on Android 9.3.91 around 2026-06-02, and an AddAttachment write-command failure-rate spike on Android 9.3.91 vs 9.3.90 for large requests.

---

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