[$250] Users receive an “Unexpected error. Please try again” message when attempting to submit report

[m-natarajan]

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.3.75-14
Reproducible in staging?: Needs Reproduction (Unable to reproduce)
Reproducible in production?: Needs Reproduction
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: @PedroEspinoza1999
Slack conversation (hyperlinked to channel name): #Expensify Bugs

Action Performed:

1. Open report
2. The admin and submitter attempt to submit the report.
3. Observe the error message.

Expected Result:

The report should submit successfully without errors.

Actual Result:

An error message appears: “Unexpected error. Please try again,” preventing the report from being submitted.

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

The screenshot for the issue is in Slack thread

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022057096908715191451
• Upwork Job ID: 2057096908715191451
• Last Price Increase: 2026-05-20

[exfy-zapier]

This has been labelled "Needs Reproduction". Follow the steps here: https://stackoverflowteams.com/c/expensify/questions/16989

[melvin-bot]

📣 @exfy-zapier! 📣
Hey, it seems we don’t have your contributor details yet! You'll only have to do this once, and this is how we'll hire you on Upwork.
Please follow these steps:

1. Make sure you've read and understood the contributing guidelines.
2. Get the email address used to login to your Expensify account. If you don't already have an Expensify account, create one here. If you have multiple accounts (e.g. one for testing), please use your main account email.
3. Get the link to your Upwork profile. It's necessary because we only pay via Upwork. You can access it by logging in, and then clicking on your name. It'll look like this. If you don't already have an account, sign up for one here.
4. Copy the format below and paste it in a comment on this issue. Replace the placeholder text with your actual details.
   
   Format:

Contributor details
Your Expensify account email: <REPLACE EMAIL HERE>
Upwork Profile Link: <REPLACE LINK HERE>

[MelvinBot]

Proposal

What is the root cause of that problem?

The "Unexpected error. Please try again later." message is a generic client-side catch-all (iou.error.other) that appears whenever the SubmitReport backend API call returns a non-200 jsonCode. The App does not surface the specific backend rejection reason — it maps every failure to the same message.

The error is set via Onyx failureData in ReportWorkflow.ts:1467-1476. Client-side validation (canSubmitReport()) controls whether the Submit button is shown at all, but it passed — meaning the button was available and the server rejected the request.

Since the error is entirely backend-driven and the issue lacks a specific reportID or requestID to trace, the exact server-side rejection reason cannot be determined from the App code alone. Common causes include: misconfigured approval workflows (invalid managerAccountID), policy billing issues, or report state conflicts.

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

This requires backend investigation to determine the specific jsonCode and rejection reason for the affected reports. The App-side code is working as designed — it shows the generic error because the backend didn't return a 200.

To diagnose: Look up the SubmitReport API calls for the affected report(s) in server logs to find the actual error code and message. Once the backend root cause is identified, the fix will be either:

1. Backend fix — if the server is incorrectly rejecting valid submissions
2. Client-side improvement — if the rejection is valid but the error message should be more specific (similar to how DEW policies already surface custom error messages via DEW_SUBMIT_FAILED actions)

What alternative solutions did you explore? (Optional)

One improvement regardless of root cause: the App could propagate the backend's error message instead of always showing the generic "Unexpected error." The DEW policy path already does this (ReportWorkflow.ts:1458-1466) — the same pattern could be extended to non-DEW submissions.

Investigation details

Error string definition: en.ts:1495 — other: 'Unexpected error. Please try again later.'

Submit flow:

1. User presses Submit → useLifecycleActions.tsx checks shouldBlockSubmit
2. Calls submitReport() in ReportWorkflow.ts:1242-1517 which builds optimistic/success/failure Onyx updates
3. API.write('SubmitReport', {reportID, managerAccountID, reportActionID}) queues the request
4. On non-200 response, OnyxUpdates.ts:48 applies failureData, attaching iou.error.other to the report action

API params (SubmitReportParams.ts): only reportID, managerAccountID, and reportActionID — all real validation happens server-side.

Possibly related issues:

• Expensify/App#89703 — "Unexpected error when approver hold expense" (same generic error, different trigger)
• Expensify/App#88235 — "Unexpected error when creating distance expense after clearing cache"

---

Next Steps for Contributor+ team: Reply with @MelvinBot implement this to create a draft PR, @MelvinBot <your feedback> to refine this analysis, or explain why you are rejecting Melvin's proposal.

[yusufdeveloper2903]

🚨 Edited by proposal-police: This proposal was edited at 2026-05-20 13:57:23 UTC.

Proposal

What is the root cause of that problem?

When submitting a report, the App fires SUBMIT_REPORT and, on a backend failure, attaches a hardcoded generic error to the optimistic submit action:

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

Lines 1462 to 1472 in e8c6aa8

	} else {
	failureData.push({
	onyxMethod: Onyx.METHOD.MERGE,
	key: `${ONYXKEYS.COLLECTION.REPORT_ACTIONS}${expenseReport.reportID}`,
	value: {
	[optimisticSubmittedReportAction.reportActionID]: {
	errors: getMicroSecondOnyxErrorWithTranslationKey('iou.error.other'),
	},
	},
	});
	}

iou.error.other is "Unexpected error. Please try again later." (en.ts:1495) — the exact message in the report. This is a generic client fallback applied for every backend rejection of SubmitReport, regardless of the actual cause.

The backend already returns the specific reason in response.message. The App reads it on the failure path, but only forwards it to telemetry via trackExpenseApiError — it is never surfaced to the user, and the client's failureData error is applied right afterward:

App/src/libs/actions/OnyxUpdates.ts

Lines 48 to 65 in e8c6aa8

	if (response.jsonCode !== 200 && request.failureData) {
	// 460 jsonCode in Expensify world means "admin required".
	// Typically, this would only happen if a user attempts an API command that requires policy admin access when they aren't an admin.
	// In this case, we don't want to apply failureData because it will likely result in a RedBrickRoad error on a policy field which is not accessible.
	// Meaning that there's a red dot you can't dismiss.
	if (response.jsonCode === 460) {
	Log.info('[OnyxUpdateManager] Received 460 status code, not applying failure data');
	return Promise.resolve();
	}
	trackExpenseApiError({
	command: request.command,
	jsonCode: response.jsonCode ?? 0,
	message: response.message,
	requestData: request.data,
	});
	return updateHandler(request.failureData);

Because the App overwrites the backend's specific reason with the generic string, the submitter and admin both see the same opaque "Unexpected error," with no indication of what's wrong and no way to act on it. This is also why the issue can't be reproduced — the real reason is discarded before anyone can see it.

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

Surface the backend's response.message on a failed write instead of letting the client's generic error mask it. The failure handler already has both request.failureData and response.message in scope, so we prefer the server-provided reason and fall back to the client error only when the backend sends none:

             trackExpenseApiError({
                 command: request.command,
                 jsonCode: response.jsonCode ?? 0,
                 message: response.message,
                 requestData: request.data,
             });

-            return updateHandler(request.failureData);
+            // Prefer the backend's specific failure reason over the action's generic fallback error,
+            // so failures like SubmitReport are actionable instead of an opaque "Unexpected error".
+            return updateHandler(applyServerErrorMessage(request.failureData, response.message));

applyServerErrorMessage walks the failureData updates and, for any errors entry that carries a generic translation key (e.g. iou.error.other), replaces it with getMicroSecondOnyxErrorObject(response.message) when response.message is non-empty — leaving action-specific errors untouched. This keeps offline/queued submit behavior intact (the existing failureData still drives the rollback) and changes only what the user reads.

What alternative solutions did you explore? (Optional)

• Routing submitReport through API.makeRequestWithSideEffects so it can read the response and set the message directly — rejected: it would make submit an online-only, non-queued request and break offline submit.
• Only changing the copy of iou.error.other — rejected: it doesn't tell the user why submit failed, so the report still can't be submitted and the issue stays unreproducible.

[melvin-bot]

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

[melvin-bot]

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

[github-actions]

⚠️ @yusufdeveloper2903 Thanks for your proposal. Please update it to follow the proposal template, as proposals are only reviewed if they follow that format (note the mandatory sections).