[Due for payment 2026-09-10] [Sentry: APP-ECR] iOS RequestMoney fails with "Unknown St13runtime_error error." — NitroFetch discards the real error message

[mountiny]

Sentry

https://expensify.sentry.io/issues/APP-ECR

Impact (snapshot at filing)

• Users (last 7d): 14
• Users (total since first seen): 59
• Events (last 7d): 1,838
• Events (total): 4,418
• First seen: 2026-06-02
• Last seen: 2026-08-19 (ongoing)
• Platform: iOS — 100% of events. Zero Android, zero web.
• App version(s): 9.4.46-10 through 9.4.54-1, App Store hybrid_app builds
• Mechanism: onunhandledrejection (non-fatal, no stack trace)

What the error actually is

Unknown St13runtime_error error. is not a server rejection and not a PDF problem. It is the name of a C++ type, printed because NitroFetch discards the real error message on its way to JavaScript.

The App replaces globalThis.fetch with NitroFetch on native (src/polyfills/NitroFetch.ts), so every API call travels this chain. The message is intact for four stages and gone for the last two:

#	Where	Message
1	URLSession → HybridNitroFetchClient.swift:75	real NSError, domain + code
2	RuntimeError.swift — Error.toCpp()	String(describing: error)
3	RuntimeError.hpp — makeException()	std::runtime_error(message)
4	JSIConverter+Promise.hpp:89	handed to the exception converter
5	JSIConverter+Exception.hpp:38-47	catch (const std::exception&) misses, catch (...) wins
6	JavaScript	Unknown St13runtime_error error.

Stage 5 is the defect:

// react-native-nitro-modules/cpp/jsi/JSIConverter+Exception.hpp
try {
  std::rethrow_exception(exception);
} catch (const std::exception& e) {
  jsi::JSError error(runtime, e.what());     // never reached
  return jsi::Value(runtime, error.value());
} catch (...) {
  std::string errorName = TypeInfo::getCurrentExceptionName();
  jsi::JSError error(runtime, "Unknown " + errorName + " error.");
  return jsi::Value(runtime, error.value());
}

Note the contradiction: catch (...) reports the type as St13runtime_error, which is std::runtime_error — exactly the type the branch above it catches. A type that fails to match its own catch clause means the throw site and the catch site disagree about type identity.

Leading hypothesis (unproven): duplicated RTTI. The exception is constructed inside the Swift module, which compiles Nitro's inline C++ headers against the Swift toolchain's libc++, while the catch site compiles against the Xcode SDK's. On Apple platforms libc++ compares type_info by pointer, so two copies of the same type never match.

Why the name is mangled

TypeInfo::demangleName() only demangles when NITRO_DEBUG is defined, and no podspec in this project ever defines it — not in Debug, not in Release. So the string reads St13runtime_error rather than std::runtime_error. That is why it looked like it came from Auth or Bedrock, which are also C++, and why it went eleven weeks without a root cause.

Why iOS only

Web never loads NitroFetch — src/polyfills/NitroFetch.web.ts leaves the platform fetch in place. Android uses Cronet through a Kotlin implementation, and Kotlin exceptions cross into C++ over JNI rather than the Swift/C++ bridge, so they never reach the stage 5 converter. The Sentry data agrees: 100% iOS across 4,418 events.

What it breaks downstream

Logging.ts classifies errors by message text, and an unrecognized message falls through every branch. Three things follow:

1. Alert flood. Each failure fires ENSURE_BUGBOT unknown API request error — roughly 32,000 log entries a week — and lands in Sentry as a stack-less rejection nobody can triage.
2. The app never goes offline. FailureTracking.ts counts only FAILED_TO_FETCH and EXPENSIFY_SERVICE_INTERRUPTED as connectivity failures, so the tracker stays at zero and the queue keeps running as if the network were fine.
3. The expense is discarded. Because the queue never pauses, SequentialQueue burns all ten retries, gives up, applies failureData and drops the request. The user lands on a Not Found page — and per the logs, Auth had often already created the transaction.

Two failures, only one of them intermittent

This is what made the bug so hard to reproduce:

• The upload failure is intermittent. It tracks the network at the moment of a large multipart POST, not the file. The same Your_ride_with_Michelle_on_August_13.pdf that burned every retry at 05:02 succeeded cleanly 16 hours later.
• The message loss is not intermittent at all. Every NitroFetch rejection is opaque, 100% of the time.

Receipt state (SCANREADY) and MIME (application/pdf) are identical across failures and successes. PDFs dominate the reports because they are the largest receipts, not because the parser dislikes them.

Proposed fix — part 1 (damage control)

A matcher for Nitro's two opaque message shapes, plus a normalization step in HttpUtils.processHTTPRequest that rethrows them under a dedicated error name while preserving the original text in title:

// src/libs/HttpUtils.ts
return fetch(url, fetchParams)
    .catch((error: unknown) => {
        if (isOpaqueNativeFetchError(error)) {
            throw new HttpsError({
                message: CONST.ERROR.NATIVE_FETCH_FAILED,
                title: error.message,
            });
        }
        throw error;
    })

NATIVE_FETCH_FAILED is then added to the three places that classify connectivity failures — Logging, FailureTracking and Reauthentication. That feeds the failure into machinery that already exists: the tracker counts it, NetworkState flips the app offline after three failures in ten seconds, the queue pauses, and the persisted request survives to be retried later.

A dedicated name rather than reusing FAILED_TO_FETCH deliberately: Failed to fetch is already a bucket of 17,000+ events across at least ten Sentry issues, much of it web ad-network noise. Folding APP-ECR into it would destroy the one clean signal we have for measuring this bug.

This does not fix the upload. The request still fails and the user still cannot create that expense on that attempt. What changes is the damage: the expense is no longer thrown away, the app correctly reports itself offline, and the alert channel stops drowning.

Proposed fix — part 2 (the actual upload bug)

Blocked on evidence that has never been logged. The underlying failure is an NSURLError whose code we have never once been able to read — -1005 (connection lost), -1001 (timeout) and -1009 (offline) each imply a different remedy.

1. Reproduce on an iOS simulator: a large PDF under Network Link Conditioner with loss injected mid-upload, reading the actual NSURLError off the Xcode console.
2. Confirm or refute the RTTI hypothesis at the repro, then patch Nitro so the message survives. That restores diagnosis for every Nitro call, not just this one.
3. Fix the upload — retry semantics, chunking or timeout, depending on step 1.

Tests

Nine assertions across two files, written before the fix and confirmed failing against it:

• tests/unit/isOpaqueNativeFetchErrorTest.ts — three Nitro message shapes recognized; five lookalikes rejected, including Unknown error and Unknown host error occurred while resolving the address.; non-Error values rejected.
• tests/unit/HttpUtilsTest.ts — the mapping and its preserved title; abort and already-recognized network errors left untouched; the failure now increments FailureTracker; three failures across the window fire the offline hard stop; Log.alert is no longer called.

Note when this ships

APP-ECR will stop receiving events and a new Sentry group will appear under NitroFetch request failed. The bug is renamed, not fixed — part 2 above is what actually fixes it.

Related

• Expensify/Expensify#655405 — original investigation, closed in favour of this issue.
• [Due for payment 2026-08-25] Add react-native-nitro-fetch #90023 — Add react-native-nitro-fetch (introduced the affected path).

Issue Owner

Current Issue Owner: @mallenexpensify

[MelvinBot]

Issue Analysis — verification of the posted root cause

Confidence: High. I independently traced every stage of this analysis against source and it holds up. The "Unknown St13runtime_error error." string is produced by the Nitro C++ exception converter losing the real message, and the App's downstream error classification never recognizes the opaque message — so the app never flips offline, the queue burns all 10 retries, and the expense is dropped. Two distinct defects: a message-loss bug in the vendored react-native-nitro-modules C++ (iOS, non-App repo) and an App-side classification gap that turns it into a dropped expense.

What's implementable in App (part 1 — damage control): the normalization + classification changes are all in App TS and are a good fix. I can draft them.
What's not in App (part 2 — the real fix): confirming/patching the Nitro RTTI bug requires an iOS-native repro and a change to the vendored library — outside the App repo, so that piece needs an internal engineer with the native toolchain; I can't propose an App code fix for it.

Evidence — every claim confirmed with file:line

The opaque message is genuine and iOS-only

• The catch (...) that produces the string exists exactly as described: std::rethrow_exception → catch (const std::exception& e) (real .what()) → catch (...) → "Unknown " + errorName + " error." — node_modules/react-native-nitro-modules/cpp/jsi/JSIConverter+Exception.hpp:38-48.
• The name is mangled because demangleName() only demangles under #ifdef NITRO_DEBUG — node_modules/react-native-nitro-modules/cpp/utils/NitroTypeInfo.cpp:38-78; getCurrentExceptionName() returns the raw mangled name otherwise (:16-23). NITRO_DEBUG is derived solely from DEBUG/NDEBUG (cpp/utils/NitroDefines.hpp:14-25) and is never hard-defined in the podspec, so a Release iOS build (NDEBUG set) emits St13runtime_error — the Itanium mangling of std::runtime_error. The #ifdef ANDROID branch there also explains why Android wouldn't show this even if it hit the path.
• Swift errors become a std::runtime_error via Error.toCpp() → makeException(String(describing: error)) (ios/core/RuntimeError.swift:37-45, ios/utils/RuntimeError.hpp:16-18), and a rejected promise routes through this converter at cpp/jsi/JSIConverter+Promise.hpp:87-90. So the type that fails to match catch (const std::exception&) genuinely is std::runtime_error — consistent with the leading duplicated-RTTI (two libc++ type_info copies) hypothesis, which source is consistent with but cannot itself prove (needs the native repro).
• NitroFetch is native-only: src/polyfills/NitroFetch.ts:6-9 replaces globalThis.fetch; the web polyfill is a no-op. Matches the 100%-iOS Sentry split.

The App-side amplifier — why the expense is dropped

• HttpUtils.processHTTPRequest's terminal .catch re-throws the raw error with no normalization — there is no isOpaqueNativeFetchError helper and no CONST.ERROR.NATIVE_FETCH_FAILED anywhere yet.
• FailureTracking.ts:23 counts only FAILED_TO_FETCH / EXPENSIFY_SERVICE_INTERRUPTED as connectivity errors → an opaque message never records a failure → the offline hard-stop never trips.
• Logging.ts:162-164 routes the unrecognized message into the else branch → fires ENSURE_BUGBOT unknown API request error (the alert flood).
• With the app still "online," the request is a generic retryable failure: RequestThrottle.sleep enforces MAX_REQUEST_RETRIES = 10, then SequentialQueue.ts:414-420 applies failureData and drops the request → Not Found page even though Auth often already created the transaction.

Not fully provable from source (as the issue already notes): the RTTI/type_info-duplication mechanism and the specific NSURLError code behind the upload failure both need the iOS repro in part 2.

Possibly-related issues / PRs

• chat-Attaching specific pdf file shows error. #92680 — "chat-Attaching specific pdf file shows error" — a PDF-upload error report on native; plausibly the same NitroFetch path surfacing to a user. Worth cross-checking once part 1 lands and gives clean signal.
• Route only http(s) requests through nitro-fetch #92655 — open PR "Route only http(s) requests through nitro-fetch" — touches NitroFetch scoping; related area, not a fix for this.
• Already linked by the author: [Due for payment 2026-08-25] Add react-native-nitro-fetch #90023 (introduced the path), Expensify/Expensify#655405 (original investigation).

No existing PR implements the NATIVE_FETCH_FAILED normalization.

I did not open a proposal template or add an External label — the analysis and fix plan are already complete and authored by you, and the issue is correctly Internal (the real fix requires native/library work).

---

Next Steps:

• @MelvinBot implement part 1 — I'll draft the App-only damage-control PR (the isOpaqueNativeFetchError helper, CONST.ERROR.NATIVE_FETCH_FAILED, HttpUtils normalization, and the Logging/FailureTracking/Reauthentication wiring) plus the nine tests.
• Part 2 (Nitro RTTI patch + iOS upload fix) needs an internal engineer with the native toolchain — I can't reproduce or fix native/library code.
• @MelvinBot <feedback> to refine.

---

view run

[mountiny]

Shared the claude artifact in Slack with Chris

[melvin-bot]

@chrispader Eep! 4 days overdue now. Issues have feelings too...

[melvin-bot]

Cross-link + a web-side data point on the same downstream failure mode

Linking from #98984. A recent real-world case matches the downstream behavior described here — an opaque connectivity failure the client never classifies, so it never flips offline and data silently goes stale — even though it is out of scope for the NitroFetch root cause in this issue:

• Platform: web (Chrome PWA on macOS). Web doesn't go through NitroFetch (the web polyfill leaves the platform fetch in place), and the error was a plain TypeError: Failed to fetch, not the Unknown St13runtime_error error. shape. So this is not a reproduction of APP-ECR.
• Why it's still relevant: the consequence is exactly the one your part-1 fix is designed to prevent. The client hit an opaque fetch failure, never registered itself as offline, sat in a multi-hour stale state, and an expense created server-side never appeared to the user — with no error surfaced. That's the same "connectivity failure isn't classified → app doesn't go offline → request/data silently lost" chain you document, just arriving via a web Failed to fetch rather than the iOS Nitro path.

Flagging it mainly to connect the two threads: the iOS opaque-message defect here and the web stale-state behavior in #98984 share the same user-facing outcome — silent data staleness with no offline signal. Worth keeping connectivity-failure classification (FailureTracking / Logging) robust across both entry points, not just the Nitro one.

Reported by @mallenexpensify via DM with MelvinBot.

[mallenexpensify]

^ Melv didn't think the above was 🔥 worthy, I think cuz it didn't appear to happen to many users. For me, not having an expense show in LHN is a big deal, borderline 🔥 though (cuz... we're an expense reporting app and swiping an expensify card should lead to an expense in LHN for any/everyone)

[melvin-bot]

@chrispader 6 days overdue. This is scarier than being forced to listen to Vogon poetry!

[chrispader]

I've found a fix for this and prepared a PR here:

• fix: NitroSQLite not propagating native errors by upgrading Skia to 2.4.18 #99541

Finishing it up right now and then we can review it!