[$250] iOS - Expense - Failed submission error is not displayed when network request fails

[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: 9.4.34-8
Reproducible in staging?: Yes
Reproducible in production?: No
If this was caught during regression testing, add the test name, ID and link from BrowserStack: #94762
Email or phone of affected tester (no customers): jose.sat94+10jul@gmail.com
Issue reported by: Applause Internal Team
Bug source: Pull Request QA execution
Device used: iPhone 13/18.6.2
App Component: Other

Action Performed:

1. Launch the Expensify app.
2. Log in with valid credentials.
3. Open a workspace chat and create multiple unapproved reports.
4. Scroll to the bottom of the chat.
5. Enable "Simulate failing network requests".
6. Create an expense.
7. Wait for the expense submission to fail.

Expected Result:

The failed expense displays a submission error, and the floating action button changes from "Approve" to "Fix".

Actual Result:

The failed expense submission error is not displayed.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7208573_1784070003193.IOS.mp4

View all open jobs on GitHub

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

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022077478368428623026
• Upwork Job ID: 2077478368428623026
• Last Price Increase: 2026-07-15

Issue Owner

Current Issue Owner: @lorretheboy

[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/493b47c7b97dfa6c8086eec3a048a4d2aa2f747f5215ab79bffb8b389bc8341b

[melvin-bot]

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

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

Issue Analysis

⚠️ This deploy blocker was auto-assigned to the merger of #94762 because it was caught while QA'ing that PR. Based on a code review, #94762 is very unlikely to be the cause — reverting it probably won't fix this. Details below.

Likely NOT caused by #94762: That PR only changed which report the "Fix" badge scrolls to (actionTargetReportActionID), not whether the error/badge appears. In the rewritten loop, brickRoadStatus: ERROR and actionBadge: FIX are still set unconditionally — even if every new preview-action lookup returns null, the fallback chain preserves the prior target and the badge still flips. The error-detection logic (SidebarUtils.getReasonAndReportActionThatHasRedBrickRoad / ReportUtils.getAllReportErrors) was untouched by the PR.

Strongest signal it isn't #94762: the bug reproduces on iOS App only. reportAttributes.ts is platform-agnostic JS — a regression there would show on Android and web too. An iOS-App-only failure points to something native/platform-specific, not this derived-value change.

Where the real cause more likely lives (needs runtime confirmation):

1. The error is never written to Onyx. With "simulate failing network" the request may keep retrying and never apply failureData, so errors never land on the transaction/report action. Check src/libs/Network/SequentialQueue.ts.
2. The parent chat is never recomputed. The propagation loop bails at if (!reportAttributes[chatReportID]) continue; — if the errored IOU report + its parent workspace chat aren't enqueued into dataToIterate on the failure update, the badge never flips. This guard is pre-existing, not introduced by fix: The floating action badge scrolls to the wrong report #94762.

Recommended next step: Don't revert #94762 on this basis alone. Instead, get runtime/log confirmation of (a) whether failureData actually applies on iOS when the network is simulated-failing, and (b) whether the parent chat is enqueued for recompute. If neither #94762 nor these paths explain it, bisect the other PRs in this StagingDeployCash that touch error propagation, generateReportAttributes, or SidebarUtils.

Investigation details & evidence

Expected flow (all confirmed intact by the PR): failed submission → errors written to TRANSACTION[id] and REPORT_ACTIONS[iouReportID][actionID] (MoneyRequestBuilder.ts failureData) → getAllReportErrors surfaces them → getReasonAndReportActionThatHasRedBrickRoad returns HAS_ERRORS → needsParentChatErrorPropagation = true → child added to erroredChildReportIDsByChat → parent chat forced to ERROR/FIX.

Note: for a submission into an existing money-request report (the repro: "multiple unapproved reports"), the error is stored on the transaction + report action, not on the report's errorFields — so recompute must be triggered via the transaction/report-action enqueue paths.

Why the three #94762-specific concerns don't hold:

• No circular import — MoneyRequestBuilder.ts has zero references back to the OnyxDerived config, and getReportPreviewAction returns null (never throws) on no match.
• New guard is logically equivalent — hoisting !chatReportID || reportID === chatReportID to an early continue selects the same set of IOU reports (whose chatReportID !== reportID) as the old inline predicate.
• getReportPreviewAction failure only affects the scroll target, not the badge, because ERROR/FIX are set unconditionally (see main finding).

Confidence: High that #94762 didn't cause the missing indicator; Medium on the actual root cause (needs runtime/log confirmation, since the local checkout is shallow and I couldn't confirm the failure Onyx write / enqueue behavior on iOS at runtime).

---

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

[MelvinBot]

🔍 Investigation Summary

Classification: Frontend bug (any fix lands in Expensify/App — the failed-submission error/FIX indicator is computed entirely in App JS)
Causing PR: Not conclusively identified — see ranked candidates below. #94762 is confirmed NOT the cause.
Related Issues: None found

Recommendation: NEEDS INVESTIGATION

I could not pin a single causing PR with high confidence. The error-detection and report-action/transaction error-enqueue paths look intact in the current staging code, so this needs runtime confirmation on iOS. Do not revert #94762 — a code review refutes it (details below). Keeping DeployBlockerCash (Frontend bug, and the issue is staging-only / not reproducible on production, so the App deploy stays blocked).

Assigned: none — no PR meets the medium-confidence bar required to assign its author/reviewers.
Labels: No changes. DeployBlockerCash kept (Frontend classification; not reproducible on production). No DeployBlocker (web) label is present.

📋 Detailed Analysis

#94762 is not the cause (confirmed)

#94762 (fix: The floating action badge scrolls to the wrong report) touches only src/libs/actions/OnyxDerived/configs/reportAttributes.ts and only changes which report the FIX badge scrolls to (actionTargetReportActionID). In the parent-chat error-propagation loop, brickRoadStatus: ERROR and actionBadge: FIX are still set unconditionally:

• App/src/libs/actions/OnyxDerived/configs/reportAttributes.ts

  Lines 595 to 601 in 0154888

  	// currentValue.reports that wasn't recomputed in this incremental run.
  	reportAttributes[chatReportID] = {
  	...chatAttributes,
  	brickRoadStatus: CONST.BRICK_ROAD_INDICATOR_STATUS.ERROR,
  	actionBadge: CONST.REPORT.ACTION_BADGE.FIX,
  	actionTargetReportActionID,
  	};

Strongest tell: the bug is reported iOS‑App‑only, but reportAttributes.ts is platform‑agnostic JS — a regression there would also appear on Android/web. (Note: Applause only tested iOS App; the other platforms are unchecked = untested, not confirmed working.)

What the affected code path does (intact on staging)

Failed submission writes errors onto the transaction and/or the IOU report action → getAllReportErrors surfaces them → SidebarUtils.getReasonAndReportActionThatHasRedBrickRoad returns HAS_ERRORS → the per-report pass sets needsParentChatErrorPropagation → the propagation loop forces the parent workspace chat to ERROR/FIX:

• Error surfacing:

  App/src/libs/ReportUtils.ts

  Lines 9431 to 9462 in 0154888

  	function getAllReportErrors(
  	report: OnyxEntry<Report>,
  	reportActions: OnyxEntry<ReportActions>,
  	allTransactions: OnyxCollection<Transaction>,
  	isReportArchived = false,
  	reports?: OnyxCollection<Report>,
  	): Errors {
  	const reportErrorFields = report?.errorFields ?? {};
  	const {errors: reportActionErrors} = getAllReportActionsErrorsAndReportActionThatRequiresAttention(report, reportActions, allTransactions, isReportArchived, reports);
  	// All error objects related to the report. Each object in the sources contains error messages keyed by microtime
  	const errorSources = {
  	...reportErrorFields,
  	...reportActionErrors,
  	};
  	const reportPolicy = allPolicies?.[`${ONYXKEYS.COLLECTION.POLICY}${report?.policyID}`];
  	if (reportErrorFields.export && !getConnectedIntegration(reportPolicy)) {
  	delete errorSources.export;
  	}
  	// Combine all error messages keyed by microtime into one object
  	const errorSourcesArray = Object.values(errorSources ?? {});
  	const allReportErrors = {};
  	for (const errors of errorSourcesArray) {
  	if (!isEmptyObject(errors)) {
  	Object.assign(allReportErrors, errors);
  	}
  	}
  	return allReportErrors;
  	}

• Child suppression + parent propagation (baseline behavior from fix: dedup RBR/Fix badge on child expense report under accessible workspace chat #89153, not this deploy):

  App/src/libs/ReportUtils.ts

  Lines 9501 to 9504 in 0154888

  	function getEffectiveReportErrors(attributes: ReportAttributesDerivedValue['reports'][string] | undefined): Errors {
  	const isPropagatingToAccessibleParent = !!attributes?.needsParentChatErrorPropagation && !attributes?.brickRoadStatus;
  	return isPropagatingToAccessibleParent ? {} : (attributes?.reportErrors ?? {});
  	}

• Recompute enqueue for report-action updates and their parent chats:

  App/src/libs/actions/OnyxDerived/configs/reportAttributes.ts

  Lines 342 to 369 in 0154888

  	const updates = [
  	...Object.keys(reportUpdates),
  	...Object.keys(reportMetadataUpdates),
  	...Object.keys(reportActionsUpdates),
  	...Object.keys(reportNameValuePairsUpdates),
  	...Array.from(reportUpdatesRelatedToReportActions),
  	...policyChangedReportKeys,
  	...personalDetailsChangedReportKeys,
  	];
  	if (useIncrementalUpdates) {
  	// if there are report-related updates, iterate over the updates
  	if (updates.length > 0 || !!transactionsUpdates || !!transactionViolationsUpdates || !!policyTagsUpdates) {
  	dataToIterate = [];
  	if (updates.length > 0) {
  	dataToIterate = prepareReportKeys(updates);
  	// When an IOU report changes, we need to re-evaluate its parent chat report as well.
  	const parentChatReportIDsToUpdate = new Set<string>();
  	for (const reportKey of dataToIterate) {
  	const report = reports[reportKey];
  	if (report?.chatReportID && report.reportID !== report.chatReportID) {
  	parentChatReportIDsToUpdate.add(`${ONYXKEYS.COLLECTION.REPORT}${report.chatReportID}`);
  	}
  	}
  	if (parentChatReportIDsToUpdate.size > 0) {
  	dataToIterate.push(...Array.from(parentChatReportIDsToUpdate));
  	}

• Recompute enqueue for transaction updates and their parent chats:

  App/src/libs/actions/OnyxDerived/configs/reportAttributes.ts

  Lines 371 to 417 in 0154888

  	if (!!transactionsUpdates || !!transactionViolationsUpdates) {
  	let transactionReportIDs: string[] = [];
  	if (transactionsUpdates) {
  	transactionReportIDs = Object.values(transactionsUpdates).map((transaction) => `${ONYXKEYS.COLLECTION.REPORT}${transaction?.reportID}`);
  	const updatedTransactionIDs = new Set(Object.keys(transactionsUpdates).map((key) => key.replace(ONYXKEYS.COLLECTION.TRANSACTION, '')));
  	if (updatedTransactionIDs.size > 0) {
  	for (const report of Object.values(reports)) {
  	if (!report?.reportID || !report.parentReportID || !report.parentReportActionID) {
  	continue;
  	}
  	const parentReportAction = reportActions?.[`${ONYXKEYS.COLLECTION.REPORT_ACTIONS}${report.parentReportID}`]?.[report.parentReportActionID];
  	const linkedTransactionID = getLinkedTransactionID(parentReportAction);
  	if (linkedTransactionID && updatedTransactionIDs.has(linkedTransactionID)) {
  	transactionReportIDs.push(`${ONYXKEYS.COLLECTION.REPORT}${report.reportID}`);
  	}
  	}
  	}
  	}
  	// Also handle transaction violations updates by extracting transaction IDs and finding their reports
  	if (transactionViolationsUpdates) {
  	const violationTransactionIDs = Object.keys(transactionViolationsUpdates).map((key) => key.replace(ONYXKEYS.COLLECTION.TRANSACTION_VIOLATIONS, ''));
  	const violationReportIDs = violationTransactionIDs
  	.map((transactionID) => transactions?.[`${ONYXKEYS.COLLECTION.TRANSACTION}${transactionID}`]?.reportID)
  	.filter(Boolean)
  	.map((reportID) => `${ONYXKEYS.COLLECTION.REPORT}${reportID}`);
  	// Also include chat reports for expense reports that have violations
  	const chatReportIDs = violationReportIDs
  	.map((reportKey) => reports?.[reportKey]?.chatReportID)
  	.filter(Boolean)
  	.map((chatReportID) => `${ONYXKEYS.COLLECTION.REPORT}${chatReportID}`);
  	transactionReportIDs = [...transactionReportIDs, ...violationReportIDs, ...chatReportIDs];
  	}
  	// A transaction change (e.g. a card expense going from pending to posted) can flip whether its
  	// expense report requires attention, but the to-do/GBR render on the parent workspace chat.
  	// Enqueue those parent chats too so their attributes don't stay stale after the transaction updates.
  	const transactionParentChatReportIDs = transactionReportIDs
  	.map((reportKey) => reports?.[reportKey]?.chatReportID)
  	.filter(Boolean)
  	.map((chatReportID) => `${ONYXKEYS.COLLECTION.REPORT}${chatReportID}`);
  	dataToIterate.push(...prepareReportKeys([...transactionReportIDs, ...transactionParentChatReportIDs]));
  	}

These paths correctly enqueue the errored report and its parent workspace chat, so on paper the FIX badge should still flip.

Ranked candidates (this StagingDeployCash, v9.4.34)

1. #95931 — "Scope reportAttributes recompute to reports referencing changed display names" (@TMisiukiewicz) — Medium‑Low
Replaced the boolean checkDisplayNamesChanged with a set-returning getDisplayNameChanges. Previously any display‑name change forced needsFullRecompute (recomputing every report, which incidentally refreshed a stale errored report + its parent chat). Now only reports referencing the changed accounts are recomputed:

• App/src/libs/actions/OnyxDerived/configs/reportAttributes.ts

  Lines 240 to 260 in 0154888

  	if (hasKeyTriggeredCompute(ONYXKEYS.PERSONAL_DETAILS_LIST, sourceValues)) {
  	displayNameChanges = getDisplayNameChanges(personalDetails);
  	if (!displayNameChanges) {
  	return currentValue ?? {reports: {}, locale: null};
  	}
  	} else if (!sourceValues) {
  	previousDisplayNames = {};
  	previousPersonalDetails = undefined;
  	} else {
  	// Save the current names now, so the first real name change can be narrowed to the reports it affects.
  	seedDisplayNamesBaseline(personalDetails);
  	}
  	// A full recompute is needed when locale changes (report names are locale-dependent) or display names change.
  	// We compare preferredLocale against currentValue?.locale so that the first locale load on startup
  	// (where both equal the same persisted value) does not trigger an unnecessary full recompute.
  	const needsFullRecompute =
  	(hasKeyTriggeredCompute(ONYXKEYS.NVP_PREFERRED_LOCALE, sourceValues) && preferredLocale !== currentValue?.locale) ||
  	displayNameChanges === RECOMPUTE_ALL ||
  	hasKeyTriggeredCompute(ONYXKEYS.CONCIERGE_REPORT_ID, sourceValues) ||
  	hasKeyTriggeredCompute(ONYXKEYS.NVP_INTRO_SELECTED, sourceValues);

• App/src/libs/actions/OnyxDerived/configs/reportAttributes.ts

  Lines 333 to 350 in 0154888

  	const personalDetailsChangedReportKeys: string[] = [];
  	if (displayNameChanges instanceof Set && useIncrementalUpdates) {
  	for (const [reportKey, report] of Object.entries(reports)) {
  	if (report && reportReferencesAccountIDs(report, displayNameChanges)) {
  	personalDetailsChangedReportKeys.push(reportKey);
  	}
  	}
  	}
  	const updates = [
  	...Object.keys(reportUpdates),
  	...Object.keys(reportMetadataUpdates),
  	...Object.keys(reportActionsUpdates),
  	...Object.keys(reportNameValuePairsUpdates),
  	...Array.from(reportUpdatesRelatedToReportActions),
  	...policyChangedReportKeys,
  	...personalDetailsChangedReportKeys,
  	];

Combined with the pre‑existing early return when a personal‑details‑triggered pass has no name change (if (!displayNameChanges) return currentValue, line 242‑244), a coalesced compute pass that carries both a PERSONAL_DETAILS_LIST change and the report‑action error write could bail out and drop the error update. This early return is pre‑existing, but #95931 removed the full‑recompute fallback that used to paper over such gaps. Needs runtime confirmation that a personal‑details update is coalesced with the failure write.

2. #95944 — "Scope first policy load recompute to reports referencing changed policies" (@TMisiukiewicz) — Low
Removed the "first policy load → recompute all" escape hatch, scoping to reports referencing changed policies. Another removal of a full‑recompute fallback in the same file; same theoretical class of staleness risk, but not directly tied to the failure write.

3. #87140 — "feat: ORTF Auto-reporting-frequency" (@TaduJR) — Low
Touches MoneyRequestBuilder.ts (expense/report grouping + optimistic/failure data construction). If auto‑reporting frequency changes which report a failed expense lands on, the error could be written where the propagation path doesn't expect it. Worth checking the failureData wiring for the "existing report" case in the repro.

4. #95805 — "Use the policies OnyxDerived dependency for the Pay/Approve badge…" (@youssef-lr) — Very Low (likely not it)
Changes only the GBR/Approve‑badge computation via a policies param; does not touch the ERROR/FIX detection path. Ruled out as the missing‑error cause but listed because it touches the same Approve→Fix badge area.

Recommended next steps

1. Get runtime/log confirmation on iOS that, with "simulate failing network requests", failureData actually applies errors to the transaction / IOU report action (vs. the request retrying forever and never applying failure data).
2. Confirm whether the reportAttributes compute pass for the failure write is being coalesced with a PERSONAL_DETAILS_LIST update and thus hitting the line 242‑244 early return.
3. If (1) and (2) check out, bisect Scope reportAttributes recompute to reports referencing changed display names #95931 first (revert or add the errored report to the incremental updates set even when the pass was triggered by a no‑op display‑name change), then Scope first policy load recompute to reports referencing changed policies #95944.
4. Re‑test on Android/web to determine whether this is genuinely iOS‑specific or simply only‑tested‑on‑iOS.

Confidence: High that #94762 is not the cause; Low on the actual root cause (needs iOS runtime/log confirmation; the local App checkout is shallow so I could not verify the failure Onyx write or the OnyxDerived coalescing behavior at runtime).