[$250] Failed distance expense creation displays incorrect receipt error when network failure is simulated

[m-natarajan]

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.34-12
Reproducible in staging?: Y
Reproducible in production?: Y
If this was caught during regression testing, add the test name, ID and link from BrowserStack:
Email or phone of affected tester (no customers):
Logs: https://stackoverflow.com/c/expensify/questions/4856
Expensify/Expensify Issue URL:
Issue reported by: @FitseTLT
Slack conversation (hyperlinked to channel name): #Expensify Bugs

Action Performed:

1. Enable Simulate Failing Network.
2. Navigate to create a Distance expense.
3. Enter the required trip details.
4. Submit the distance expense or refresh the page
5. Observe the displayed error message.

Expected Result:

The application should display a network-related error indicating that the distance expense could not be created due to connectivity issues.

Actual Result:

A receipt-related error is displayed, even though the user is creating a distance expense and no receipt upload is involved.

Workaround:

Unknown

Platforms:

Select the officially supported platforms where the issue was reproduced:

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

Screenshots/Videos

receipt.upload.error.appears.for.a.failing.distance.request.mp4

Recording.3222.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

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

Issue Owner

Current Issue Owner: @youssef-lr

[MelvinBot]

Proposal

What is the root cause of that problem?

A regression introduced same-day in #95772 (refactor). The transaction's own error is correct — but a synthesized fallback receipt error overrides it in the receipt view.

When a distance-expense create fails offline, two things happen:

1. transaction.errors is set to the correct generic message. getReceiptError() is called with isScanRequest = false (distance ≠ scan), so it short-circuits to iou.error.genericCreateFailureMessage — MoneyRequestBuilder.ts:339-340.
2. Because a new IOU report is created, report.errorFields.createChat is also set — MoneyRequestBuilder.ts:1021.

The bug is in MoneyRequestReceiptView.tsx:385-395. fallbackReceiptError fabricates a RECEIPT_ERROR object whenever there is a report-creation error and the transaction has a receipt — and distance expenses always carry a generated map e-receipt (hasReceipt is true). That fabricated receipt error is merged into the displayed errors (line 402), and DotIndicatorMessage.tsx:75-83 then renders the "receipt upload failed" UI (with a Save receipt download button) and suppresses the real generic/network message. The guard at line 386 never excludes e-receipt transactions.

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

Exclude distance transactions from the fallbackReceiptError guard in MoneyRequestReceiptView.tsx:386, by adding isDistanceRequest(transaction) to the early-return condition. When the fallback returns {}, errors falls through to the correct generic message and DotIndicatorMessage renders it as normal text.

isDistanceRequest (TransactionUtils/index.ts:152) is the conservative fix scoped to the reported case.

What alternative solutions did you explore? (Optional)

A broader guard using an e-receipt check would also cover per-diem and other generated-receipt expenses that likely hit the same bug on report-creation failure. Note the existing isEReceiptTransaction at MoneyRequestReceiptView.tsx:290 requires !hasReceiptSource, so it would not catch distance (which has a source) — a dedicated broader check would be needed if we want to cover per-diem too. Worth confirming whether per-diem reproduces the same symptom before widening scope.

Evidence chain

• getReceiptError returns generic message for non-scan: MoneyRequestBuilder.ts:329-351
• isScanRequest is true only for SCAN: TransactionUtils/index.ts:202
• hasReceipt true when receipt.state exists (distance gets a generic receipt): TransactionUtils/index.ts:483
• getCreationReportErrors reads errorFields.createChat: ReportUtils.ts:10258
• Receipt errors suppress the generic message in the dot-indicator: DotIndicatorMessage.tsx:75-83, receipt UI at line 123
• fallbackReceiptError was added 2026-07-15 in the #95772 refactor — matching the report date, i.e. a fresh regression.

---

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

[MobileMage]

🚨 Edited by proposal-police: This proposal was edited at 2026-07-15 21:19:19 UTC.

Proposal

Please re-state the problem that we are trying to solve in this issue.

When "Simulate failing network requests" is enabled and a distance expense is submitted (or the page is refreshed so the queued request fails), the expense view shows a receipt-related error ("Receipt upload failed. Save the receipt, or delete the expense and lose it." with a Save receipt button) even though a distance expense involves no receipt upload at all.

What is the root cause of that problem?

Every non-manual distance expense is created with an app-generated map placeholder receipt. createDistanceRequest in src/libs/actions/IOU/Split.ts attaches it before building the optimistic data, and buildOptimisticTransaction keeps it on the optimistic transaction because receipt.source is set, so the stored transaction ends up with receipt: {source: ReceiptGeneric, state: 'OPEN'}:

App/src/libs/actions/IOU/Split.ts

Lines 1998 to 2002 in c81c4b7

	const optimisticReceipt: Receipt | undefined = !isManualDistanceRequest
	? {
	source: ReceiptGeneric as ReceiptSource,
	state: CONST.IOU.RECEIPT_STATE.OPEN,
	}

When the simulated failure fires, HttpUtils throws FAILED_TO_FETCH and SequentialQueue applies the request's failureData immediately instead of retrying (src/libs/Network/SequentialQueue.ts:228-236). That failureData is actually correct for distance: getReceiptError in src/libs/actions/IOU/MoneyRequestBuilder.ts:339 returns the plain iou.error.genericCreateFailureMessage translation-key error because !isScanRequest is true for a distance transaction, and buildOnyxDataForMoneyRequest additionally writes errorFields: {createChat: ...} onto the new transaction-thread report (MoneyRequestBuilder.ts:1056-1068). So nothing in Onyx contains a receipt error — the receipt error is synthesized at render time.

The symptom is produced in MoneyRequestReceiptView. It derives reportCreationError from getCreationReportErrors(report) — truthy after the failure because the transaction-thread report now has errorFields.createChat — and then unconditionally fabricates a CONST.IOU.RECEIPT_ERROR object whenever report creation failed and the transaction "has a receipt":

App/src/components/ReportActionItem/MoneyRequestReceiptView.tsx

Lines 385 to 389 in c81c4b7

	const fallbackReceiptError = useMemo(() => {
	if (hasReceiptUploadError || isEmptyObject(reportCreationError) || !hasReceipt || !transaction?.receipt) {
	return {};
	}

hasReceipt is !!transaction?.receipt?.state, which is true for distance because of the state: 'OPEN' map placeholder, so fallbackReceiptError fires and gets merged into the errors passed to OfflineWithFeedback. DotIndicatorMessage then gives receipt errors absolute precedence (uniqueMessages.find(isReceiptError)) and renders only the receipt UI, suppressing the correct generic create-failure message that is also present in the transaction's errors:

App/src/components/DotIndicatorMessage.tsx

Lines 135 to 139 in c81c4b7

	accessibilityRole={isErrorMessage ? CONST.ROLE.ALERT : undefined}
	accessibilityLiveRegion={isErrorMessage ? 'assertive' : undefined}
	>
	{translate('iou.error.receiptUploadFailedMessage')}
	</Text>

The fallback was added in commit 3293e33f68e ("feat: update error uploading receipt screen") so that a user-uploaded receipt file can be saved before a failed expense is deleted, but it never accounted for distance expenses whose "receipt" is generated by the app — its Save receipt button would just download the bundled generic map SVG.

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

The fix belongs where the bogus error is synthesized: skip the fallback for distance expenses inside fallbackReceiptError in MoneyRequestReceiptView.tsx, using the isDistanceRequest flag the component already computes at line 187 from isDistanceRequestTransactionUtils(displayedTransaction) (which covers the legacy distance type plus all distance-map/distance-gps/distance-manual/distance-odometer variants):

const fallbackReceiptError = useMemo(() => {
    if (hasReceiptUploadError || isEmptyObject(reportCreationError) || !hasReceipt || !transaction?.receipt || isDistanceRequest) {
        return {};
    }
    ...
}, [hasReceiptUploadError, reportCreationError, hasReceipt, transaction, isDistanceRequest]);

With the fallback empty, the errors memo falls through to errorsWithoutReportCreation, which already carries the iou.error.genericCreateFailureMessage error written by the failureData, so the user sees "Unexpected error submitting this expense. Please try again later." — the same message a failed manual expense shows, which is the established pattern for creation failures (there is no dedicated network-failure error in this flow, and the failure is applied precisely because the request will not be retried). The dismiss flow is unaffected: onClose sees no receipt error and calls dismissReceiptError directly, without the misleading "dismiss receipt error" confirmation modal. Scan and manual expenses with a real attached receipt still hit the fallback because isDistanceRequest is false for them, so the save-receipt protection this fallback was built for is fully preserved.

What alternative solutions did you explore? (Optional)

We considered fixing this in the write path (getReceiptError/failureData), but the Onyx data is already correct for distance — the receipt error only exists at render time, so patching the action layer wouldn't help. We also considered a narrower guard using isMapBasedDistanceRequest so odometer/manual distance expenses with a real user photo keep the save-receipt affordance, but "Receipt upload failed" is misleading for any distance creation failure (the receipt isn't what failed), so gating on isDistanceRequest is the cleaner and more predictable behavior.

[samranahm]

Proposal

What is the root cause of that problem?

When Simulate Failing Network is on and a user submits a distance expense, the optimistic transaction is created with a placeholder receipt (the route map thumbnail, so it carries receipt.source/filename). When the request fails, the failure onyxData for the distance flow writes the transaction errors using the receipt error helper getReceiptError in ErrorUtils.ts instead of a generic network error.

Distance creation is handled in IOU.ts (getDistanceRequestOnyxData / createDistanceRequest), where the failureData for the transaction sets errors via ErrorUtils.getReceiptError(...). That helper builds a receipt-specific error object (translation key iou.error.receiptFailureMessage plus the receipt source/filename), because it is designed for scan/manual receipt uploads.

App/src/libs/Log.ts

Lines 112 to 120 in c81c4b7

	const Log = new Logger({
	serverLoggingCallback,
	clientLoggingCallback: (message, extraData) => {
	console.debug(message, extraData);
	},
	maxLogLinesBeforeFlush: 150,
	isDebug: true,
	getContextEmail: getCurrentUserEmail,
	});

Since distance expenses reuse the same failure path as receipt-based expenses, the receipt error message is surfaced in the report action even though no receipt was uploaded, which is what the tester sees in the video. The expected outcome is a generic "could not be created due to connectivity" error, but the receipt branch always runs.

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

1. In IOU.ts, locate the distance failure onyxData in getDistanceRequestOnyxData/createDistanceRequest where the transaction errors are populated with ErrorUtils.getReceiptError(...). For a distance transaction (TransactionUtils.isDistanceRequest(transaction) is true) there is no user-uploaded receipt, so it should use the generic error object instead.

const failureError = TransactionUtils.isDistanceRequest(transaction)
    ? ErrorUtils.getMicroSecondOnyxErrorObject(Localize.translateLocal('iou.error.genericCreateFailureMessage'))
    : ErrorUtils.getReceiptError(receipt, receipt?.filename ?? filename, isScanRequest, errorKey);

This keeps the existing receipt behavior for scan/manual expenses while giving distance expenses a network-appropriate message.

2. In ErrorUtils.ts, guard getReceiptError so that when the passed receipt is a distance placeholder (no real source/filename from an upload), it falls back to a generic error rather than a receipt-failure message. This is a defensive fix in case other flows reuse the same helper for distance transactions.

Because the failure branch no longer forces the receipt message for distance transactions, the report action will render the correct network/connectivity error, resolving the mismatch shown in the issue.

What alternative solutions did you explore? (Optional)

Reminder: Please use plain English, be brief and avoid jargon. Feel free to use images, charts or pseudo-code if necessary. Do not post large multi-line diffs or write walls of text. Do not create PRs unless you have been hired for this job.

[ahmdshrif]

Proposal

Please re-state the problem that we are trying to solve in this issue.

When a distance expense fails to be created (e.g. a simulated network failure), the UI surfaces a receipt error even though a distance expense's failure has nothing to do with a scanned receipt. The user should see a generic create-failure message, not a receipt error.

What is the root cause of that problem?

The error attached on failure is decided in a single place, getReceiptError, which only falls back to the generic message when the receipt is empty or the request is not a scan request:

return isEmptyObject(receipt) || !isScanRequest
    ? getMicroSecondOnyxErrorWithTranslationKey('iou.error.genericCreateFailureMessage', errorKey)
    : getMicroSecondOnyxErrorObject({error: CONST.IOU.RECEIPT_ERROR, source: receipt.source?.toString() ?? '', ...})

App/src/libs/actions/IOU/MoneyRequestBuilder.ts

Lines 339 to 351 in c81c4b7

	return isEmptyObject(receipt) || !isScanRequest
	? getMicroSecondOnyxErrorWithTranslationKey('iou.error.genericCreateFailureMessage', errorKey)
	: getMicroSecondOnyxErrorObject(
	{
	error: CONST.IOU.RECEIPT_ERROR,
	source: receipt.source?.toString() ?? '',
	filename: filename ?? '',
	action: action ?? '',
	retryParams: formattedRetryParams,
	},
	errorKey,
	);
	}

A distance expense carries a non-empty receipt (the generated route/map image), so the receipt-error shape can be produced/rendered for it. The receipt preview then reads that error object as a receipt error and pairs it with transaction.receipt.source, so a failed distance creation renders as a receipt error:

App/src/libs/ReceiptUtils.ts

Line 52 in c81c4b7

const errors = findLast(transaction?.errors) as ReceiptError | undefined;

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

Make getReceiptError treat a distance request the same as a non-scan request, so the failure surfaces the generic message rather than a receipt error. Pass/derive isDistanceRequest and widen the fallback guard:

return isEmptyObject(receipt) || !isScanRequest || isDistanceRequest
    ? getMicroSecondOnyxErrorWithTranslationKey('iou.error.genericCreateFailureMessage', errorKey)
    : getMicroSecondOnyxErrorObject({error: CONST.IOU.RECEIPT_ERROR, ...});

The distance transaction is already available at each call site (isDistanceRequestTransactionUtils(transaction)), so this is a small, localized change.

Regression check: verify scan-request failures still show the receipt error and its retry/dismiss affordance, and that manual/per-diem failures continue to show the generic message.

[lorretheboy]

Proposal

Please re-state the problem that we are trying to solve in this issue.

Creating a distance expense with Simulate Failing Network on shows "Receipt upload failed. Save the receipt, or delete the expense and lose it." with a Save receipt button, even though no receipt was ever uploaded. The user should see the generic expense-creation failure that the app already stored for this transaction.

What is the root cause of that problem?

The fallbackReceiptError memo in MoneyRequestReceiptView is not a fallback at all — its guard is logically equivalent to !isScanRequest(transaction), so it fires only when the action layer has already decided the failure is not a receipt failure, and it overrides that decision. It is dead code for the one case it was written for.

Here is the guard and the errors memo that consumes it:

App/src/components/ReportActionItem/MoneyRequestReceiptView.tsx

Lines 385 to 405 in c81c4b7

	const fallbackReceiptError = useMemo(() => {
	if (hasReceiptUploadError || isEmptyObject(reportCreationError) || !hasReceipt || !transaction?.receipt) {
	return {};
	}
	return getMicroSecondOnyxErrorObject({
	error: CONST.IOU.RECEIPT_ERROR,
	source: transaction.receipt.source?.toString() ?? '',
	filename: transaction.receipt.filename ?? '',
	});
	}, [hasReceiptUploadError, reportCreationError, hasReceipt, transaction]);
	const errors = useMemo(() => {
	if (hasReceiptUploadError) {
	return errorsWithoutReportCreation;
	}
	if (!isEmptyObject(fallbackReceiptError)) {
	return {...errorsWithoutReportCreation, ...fallbackReceiptError};
	}
	return isEmptyObject(errorsWithoutReportCreation) ? reportCreationError : errorsWithoutReportCreation;
	}, [hasReceiptUploadError, fallbackReceiptError, errorsWithoutReportCreation, reportCreationError]);

The proof is that on failure the action layer always writes transaction.errors = getReceiptError(receipt, filename, isScanRequest, …), on both branches of buildOnyxDataForMoneyRequest — the selfDM split branch:

App/src/libs/actions/IOU/MoneyRequestBuilder.ts

Lines 974 to 993 in c81c4b7

	if (isSelfDMSplit && selfDMReportID) {
	onyxData.failureData?.push(
	{
	onyxMethod: Onyx.METHOD.MERGE,
	key: `${ONYXKEYS.COLLECTION.TRANSACTION}${transaction.transactionID}`,
	value: {
	errors: getReceiptError(transaction.receipt, transaction.receipt?.filename, isScanRequest, errorKey, CONST.IOU.ACTION_PARAMS.MONEY_REQUEST, retryParams),
	pendingFields: clearedPendingFields,
	},
	},
	{
	onyxMethod: Onyx.METHOD.MERGE,
	key: `${ONYXKEYS.COLLECTION.REPORT_ACTIONS}${selfDMReportID}`,
	value: {
	[iou.action.reportActionID]: {
	errors: getReceiptError(transaction.receipt, transaction.receipt?.filename, isScanRequest, errorKey, CONST.IOU.ACTION_PARAMS.MONEY_REQUEST, retryParams),
	},
	},
	},
	);

and the standard flow:

App/src/libs/actions/IOU/MoneyRequestBuilder.ts

Lines 1025 to 1032 in c81c4b7

	{
	onyxMethod: Onyx.METHOD.MERGE,
	key: `${ONYXKEYS.COLLECTION.TRANSACTION}${transaction.transactionID}`,
	value: {
	errors: getReceiptError(transaction.receipt, transaction.receipt?.filename, isScanRequest, errorKey, CONST.IOU.ACTION_PARAMS.MONEY_REQUEST, retryParams),
	pendingFields: clearedPendingFields,
	},
	},

and getReceiptError returns a RECEIPT_ERROR object exactly when the receipt is non-empty and it is a scan request, otherwise the generic message:

App/src/libs/actions/IOU/MoneyRequestBuilder.ts

Lines 339 to 351 in c81c4b7

	return isEmptyObject(receipt) || !isScanRequest
	? getMicroSecondOnyxErrorWithTranslationKey('iou.error.genericCreateFailureMessage', errorKey)
	: getMicroSecondOnyxErrorObject(
	{
	error: CONST.IOU.RECEIPT_ERROR,
	source: receipt.source?.toString() ?? '',
	filename: filename ?? '',
	action: action ?? '',
	retryParams: formattedRetryParams,
	},
	errorKey,
	);
	}

The view reads that back as hasReceiptUploadError:

App/src/components/ReportActionItem/MoneyRequestReceiptView.tsx

Lines 366 to 374 in c81c4b7

	const errorsWithoutReportCreation = useMemo(
	() => ({
	...(transaction?.errorFields?.route ?? transaction?.errorFields?.waypoints ?? transaction?.errors),
	...parentReportAction?.errors,
	}),
	[transaction?.errorFields?.route, transaction?.errorFields?.waypoints, transaction?.errors, parentReportAction?.errors],
	);
	const reportCreationError = useMemo(() => (getCreationReportErrors(report) ? getMicroSecondOnyxErrorWithTranslationKey('report.genericCreateReportFailureMessage') : {}), [report]);
	const hasReceiptUploadError = Object.values(errorsWithoutReportCreation).some((error) => isReceiptError(error));

Putting those together: the fallback requires !hasReceiptUploadError and a non-empty transaction.receipt. A non-empty receipt with no stored RECEIPT_ERROR can only mean isScanRequest === false. So fallbackReceiptError fires iff the transaction has a receipt, report creation failed, and it is not a scan — i.e. precisely and only where getReceiptError deliberately chose the generic message. Conversely, for a real scan failure the fallback never runs, because transaction.errors already holds the authoritative RECEIPT_ERROR (complete with source, filename, action and retryParams) and line 398 short-circuits to it.

Distance is simply the expense type that trips this, because a map/GPS distance request always carries a generated placeholder receipt:

App/src/libs/actions/IOU/Split.ts

Lines 1998 to 2003 in c81c4b7

	const optimisticReceipt: Receipt | undefined = !isManualDistanceRequest
	? {
	source: ReceiptGeneric as ReceiptSource,
	state: CONST.IOU.RECEIPT_STATE.OPEN,
	}
	: receipt;

which makes hasReceipt true:

App/src/libs/TransactionUtils/index.ts

Lines 483 to 485 in c81c4b7

	function hasReceipt(transaction: OnyxInputOrEntry<Transaction> | undefined): boolean {
	return !!transaction?.receipt?.state || hasEReceipt(transaction);
	}

Once the fabricated error is merged in, DotIndicatorMessage renders the receipt UI and returns early, discarding every other message — which is why the real error never appears:

App/src/components/DotIndicatorMessage.tsx

Lines 123 to 173 in c81c4b7

	if (receiptError) {
	const isStackedLayout = !(isInNarrowPaneModal && !isSmallScreenWidth);
	const messageRow = (
	<View style={[styles.dotIndicatorMessage, isStackedLayout && styles.alignItemsStart, styles.flex1]}>
	<View style={styles.offlineFeedbackErrorDot}>
	<Icon
	src={expensifyIcons.DotIndicator}
	fill={isErrorMessage ? theme.danger : theme.success}
	/>
	</View>
	<Text
	style={[StyleUtils.getDotIndicatorTextStyles(isErrorMessage), textStyles, styles.flex1]}
	accessibilityRole={isErrorMessage ? CONST.ROLE.ALERT : undefined}
	accessibilityLiveRegion={isErrorMessage ? 'assertive' : undefined}
	>
	{translate('iou.error.receiptUploadFailedMessage')}
	</Text>
	</View>
	);
	const buttonsRow = (
	<View style={[styles.flexRow, styles.gap3]}>
	<Button
	small
	text={translate('iou.error.saveReceipt')}
	onPress={() => {
	fileDownload(translate, receiptError.source, receiptError.filename);
	}}
	/>
	<Button
	small
	danger
	text={translate('iou.deleteExpense', {count: 1})}
	onPress={dismissError}
	/>
	</View>
	);
	if (!isStackedLayout) {
	return (
	<View style={[styles.flexRow, styles.gap3, styles.alignItemsCenter, style]}>
	{messageRow}
	{buttonsRow}
	</View>
	);
	}
	return (
	<View style={style}>
	{messageRow}
	<View style={styles.mt3}>{buttonsRow}</View>
	</View>
	);
	}

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

Delete fallbackReceiptError and let the action layer's error stand as the single source of truth. Remove the memo at L385-395 and collapse the errors memo to:

const errors = useMemo(
    () => (isEmptyObject(errorsWithoutReportCreation) ? reportCreationError : errorsWithoutReportCreation),
    [errorsWithoutReportCreation, reportCreationError],
);

This is a pure reduction, not a behaviour trade: when hasReceiptUploadError is true, errorsWithoutReportCreation is non-empty by definition, so the existing first branch already returns exactly what this one-liner returns. Both removed branches were redundant with the last line — the fabrication was the only thing standing between the user and the correct message. Scan failures keep the receipt-error UI and a working Save button, because they render from the real stored RECEIPT_ERROR, not from this memo.

For the reported case, errors now falls through to iou.error.genericCreateFailureMessage written by the failure data, so the user sees "Unexpected error creating this expense. Please try again later." Nothing else depends on the fabricated object: dismissReceiptError is driven by errorsWithoutReportCreation / reportCreationError / pendingAction, and hasReceiptUploadError is still used for the audit rows, so both stay. getMicroSecondOnyxErrorObject becomes unused in this file and should be dropped from the import.

Regression checks: a failed scan still shows "Receipt upload failed" with a working Save receipt; failed distance (map, GPS, split, tracked) and per diem show the generic message.

What alternative solutions did you explore? (Optional)

Keeping the memo and adding one more predicate to its guard — !transaction?.receipt?.filename, isDistanceRequest(transaction), or a map-distance check — fixes the symptom, but it leaves a second rule in the view that re-derives, and can still contradict, a decision the action layer already made correctly; each of those predicates only patches the subset of !isScanRequest someone happened to think of. A filename guard also mis-fires in the other direction for any receipt already stored on the server (filename present, nothing at risk of being lost), and it wouldn't protect odometer distance expenses the way it appears to — their photos live in comment.odometerStartImage / odometerEndImage, not transaction.receipt.

Changing getReceiptError to special-case distance was also considered and rejected: its !isScanRequest branch already returns the generic message for distance today, so that edit is a no-op for this bug.

If a future non-scan flow ever creates a transaction holding a real user file the user could lose, the affordance should be restored by widening getReceiptError's gate in the action layer — one predicate, in one place — rather than by reintroducing a competing rule in the view. Today no such flow exists at creation time; getTransactionWithPreservedLocalReceiptSource only preserves a local receipt source for scan requests, which is the same assumption:

App/src/libs/actions/IOU/MoneyRequestBuilder.ts

Lines 416 to 417 in c81c4b7

	function getTransactionWithPreservedLocalReceiptSource(transaction: OnyxTypes.Transaction, isScanRequest: boolean): OnyxTypes.Transaction {
	if (isScanRequest && isLocalFile(transaction.receipt?.source)) {

[melvin-bot]

Triggered auto assignment to Contributor-plus team member for initial proposal review - @marufsharifi (External)

[melvin-bot]

Job added to Upwork: https://www.upwork.com/jobs/~022077503006812696186

[Dip-G-Git]

Proposal

What is the root cause of that problem?

• Primary Root Cause: src/components/ReportActionItem/MoneyRequestReceiptView.tsx:385-395 — the fallbackReceiptError memo fabricates a RECEIPT_ERROR object using only three conditions, none of which check whether the "receipt" is a real user-uploaded/scanned file:

const fallbackReceiptError = useMemo(() => {
    if (hasReceiptUploadError || isEmptyObject(reportCreationError) || !hasReceipt || !transaction?.receipt) {
        return {};
    }
    return getMicroSecondOnyxErrorObject({
        error: CONST.IOU.RECEIPT_ERROR,
        source: transaction.receipt.source?.toString() ?? '',
        filename: transaction.receipt.filename ?? '',
    });
}, [hasReceiptUploadError, reportCreationError, hasReceipt, transaction]);

A map distance expense carries a generated map receipt, so hasReceipt is true (see below) and transaction.receipt exists. When the network is simulated as failing, reportCreationError is non-empty, so this memo manufactures a fake receipt error even though the user never uploaded or scanned anything.

• Secondary Root Cause: src/libs/TransactionUtils/index.ts:483-485 — hasReceipt treats "has a receipt state OR e-receipt" as "has a receipt", which is true for distance's generated map:

function hasReceipt(transaction: OnyxInputOrEntry<Transaction> | undefined): boolean {
    return !!transaction?.receipt?.state || hasEReceipt(transaction);
}

hasReceipt conflates "has any receipt-shaped object" with "user provided a receipt", so it is the wrong signal to gate a retry/save-receipt error on.

• Affected Files:
  • src/components/ReportActionItem/MoneyRequestReceiptView.tsx (385-405)
  • src/libs/TransactionUtils/index.ts (483-485, hasReceiptSource 488-490, isScanRequest 202-204) — read only, for the guard signal
  • src/components/DotIndicatorMessage.tsx (122-171) — read only, where the wrong UI renders
• Affected Component(s): MoneyRequestReceiptView → OfflineWithFeedback → DotIndicatorMessage
• Bug Category: Model-vs-reality divergence (a synthetic placeholder receipt is treated as a genuine uploaded receipt) + wrong predicate (hasReceipt instead of "has an uploadable receipt").
• Mechanism (unbroken, line-numbered):
  1. Offline distance submit fails → the new IOU report gets a creation error, so getCreationReportErrors(report) is truthy and reportCreationError is non-empty — MoneyRequestReceiptView.tsx:382.
  2. hasReceipt is true for the map receipt — MoneyRequestReceiptView.tsx:198 via TransactionUtils/index.ts:483.
  3. No real receipt-upload error exists, so hasReceiptUploadError is false — MoneyRequestReceiptView.tsx:383.
  4. All four early-return conditions fail, so fallbackReceiptError returns a fabricated RECEIPT_ERROR — MoneyRequestReceiptView.tsx:385-395.
  5. errors merges that fabricated error in and it wins over the real message — MoneyRequestReceiptView.tsx:397-405.
  6. DotIndicatorMessage finds receiptError via isReceiptError (matches error === RECEIPT_ERROR, ErrorUtils.ts), renders "Receipt upload failed" + a Save receipt download button, and drops the real message — DotIndicatorMessage.tsx:73, 122-171.

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

• Fix Option 1 (Recommended): Gate fallbackReceiptError on the transaction actually having an uploadable receipt source rather than on hasReceipt. A distance map receipt is generated locally and has no user-provided file to "save" or "retry", so it must not produce a RECEIPT_ERROR. Add !hasReceiptSource(transaction) and isDistanceRequest(transaction) protection to the early return in MoneyRequestReceiptView.tsx:386.

  Before:

  if (hasReceiptUploadError || isEmptyObject(reportCreationError) || !hasReceipt || !transaction?.receipt) {
      return {};
  }

  After:

  if (hasReceiptUploadError || isEmptyObject(reportCreationError) || !hasReceipt || !transaction?.receipt || isDistanceRequestTransactionUtils(transaction)) {
      return {};
  }

  Both isDistanceRequestTransactionUtils and hasReceiptSource are already imported in this file (lines 51-58), so no new imports are needed. When the memo returns {}, errors (line 401) falls through to reportCreationError, which DotIndicatorMessage renders as the correct generic/network message. Why best: it fixes the exact place the fake error is born, is the smallest scoped change, and leaves genuine scan/manual-upload failures (which have a real receipt.source and are not distance) untouched.

• Fix Option 2 (Alternative): Replace the hasReceipt guard with an "uploaded receipt" predicate for scan expenses only — gate on isScanRequest(transaction) since only scan requests carry a user-uploaded file at creation time. Trade-off: broader and cleaner conceptually, but it also changes behavior for manual/per-diem/time expenses that today happen to hit this fallback; needs regression confirmation that those still show the right copy, so it is riskier than Option 1.

• Revert Option: Revert PR Part 5: Remove Onyx.connect() for the key: ONYXKEYS.COLLECTION.TRANSACTION_VIOLATIONS in src/libs/actions/IOU.ts #95772 (which introduced fallbackReceiptError). Not ideal — it would remove the legitimate report-creation retry affordance for real scan/upload failures that the fallback was designed to surface.

• Alternate fix (rejected): Fix downstream in DotIndicatorMessage.tsx by ignoring receipt errors for distance. Rejected because the component only receives an opaque messages object with no transaction context, and MoneyRequestReceiptView would still compute the wrong errors/onClose (dismiss-modal) path — it masks the symptom, not the cause.

Fix	Description	Files to Change	Effort	Risk	Status
1	Add isDistanceRequest(transaction) to the fallbackReceiptError early return	MoneyRequestReceiptView.tsx (1 line)	Low	Low	Recommended
2	Gate the fallback on isScanRequest(transaction) instead of hasReceipt	MoneyRequestReceiptView.tsx (1 line)	Low	Medium	Alternative
3	Revert #95772	multiple	Med	Med	Not ideal

What alternative solutions did you explore? (Optional)

• Add only the m flag — matches the line but still erases the title (rejected above).
• Move the subtitle to its own label on the server — leaves old charts broken and keeps the App brittle.
• Revert the localizer — restores the original wrong behavior.

Reminder: Please use plain English, be brief and avoid jargon. Feel free to use images, charts or pseudo-code if necessary. Do not post large multi-line diffs or write walls of text. Do not create PRs unless you have been hired for this job.