[$250] Reports - Submit action is missing from the selection dropdown in offline mode

[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.3.79-1
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught during regression testing, add the test name, ID and link from BrowserStack: #91257
Email or phone of affected tester (no customers): applausetester+bm55673@applause.expensifail.com
Issue reported by: Applause Internal Team
Bug source: Pull Request QA execution
Device used: Web, android
App Component: Money Requests

Action Performed:

1. Go to https://staging.new.expensify.com/
2. Create an expense in the WS chat
3. Go to Spend > Reports
4. Go offline
5. Select the expense
6. Click on the action dropdown

Expected Result:

Submit action should be available

Actual Result:

Submit action is missing from the selection dropdown in offline mode

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7160176_1779407922531.bandicam_2026-05-22_02-57-34-937.mp4

View all open jobs on GitHub

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

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022057680313226055367
• Upwork Job ID: 2057680313226055367
• Last Price Increase: 2026-05-22

Issue Owner

Current Issue Owner: @arosiclair

[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/032f2d91cc5429d5f97376120bfb01e0b073f5e94b76a00870d8c88aa4910d1c

[MelvinBot]

Proposal

What is the root cause of that problem?

PR #91257 introduced getSubmitExclusion to hide the Submit action for non-owners. The function compares ownerAccountID (type number | undefined) against currentAccountID (type number). When offline, ownerAccountID can be undefined (the report data isn't fully available), and undefined !== currentAccountID evaluates to true — so Submit is incorrectly excluded even for the report owner.

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

Guard against undefined in getSubmitExclusion so that a missing ownerAccountID does not trigger the exclusion:

ownerAccountID !== undefined && ownerAccountID !== currentAccountID

This is a one-line change at SearchUIUtils.ts:2422. When ownerAccountID is unknown, we should not assume the user is a non-owner.

What alternative solutions did you explore? (Optional)

An alternative is to ensure the report object is always available when building search sections offline (propagating ownerAccountID through Onyx). However, this is a larger change and the undefined guard is the correct minimal fix — the function's contract should handle undefined gracefully since its own type signature already accepts it.

Investigation details

The three call sites that can pass undefined:

• SearchUIUtils.ts:2138 — transaction view, via report?.ownerAccountID
• SearchUIUtils.ts:2797 — report view, via reportItem.ownerAccountID (optional field on Report type)
• SearchUIUtils.ts:2862 — transaction-within-reports view, via report?.ownerAccountID

When the device is offline, the report object may be undefined (not synced) or its ownerAccountID field may be missing (it's optional per Report.ts). In both cases, getSubmitExclusion receives undefined and incorrectly returns [SUBMIT] as an exclusion, causing getAction to skip Submit and fall back to View.

---

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.

[MobileMage]

Proposal

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

When a user goes offline and selects a report in the Reports (Spend > Reports) view, the Submit action is missing from the bulk action dropdown. Since the app is offline-first and supports optimistic updates, Submit should be available offline just like it is online.

What is the root cause of that problem?

The shouldShowSubmitOption boolean in useSearchBulkActions.ts unconditionally gates the Submit option behind !isOffline. When the user is offline, this condition is false regardless of whether the selected reports are actually submittable, so the Submit option is never added to the options array.

App/src/hooks/useSearchBulkActions.ts

Lines 1251 to 1256 in 8dc363e

	const shouldShowSubmitOption =
	!isOffline &&
	areSelectedTransactionsIncludedInReports &&
	(selectedReports.length
	? selectedReports.every((report) => report.allActions.includes(CONST.SEARCH.ACTION_TYPES.SUBMIT))
	: selectedTransactionsKeys.every((id) => selectedTransactions[id].action === CONST.SEARCH.ACTION_TYPES.SUBMIT));

Compare this to the Approve and Pay options: both also gate on !isOffline at the visibility level (lines 1177 and 1290), but Submit is the only one that is expected to work offline because submitMoneyRequestOnSearch (called in the onSelected handler on line 1281) supports optimistic updates.

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

Remove !isOffline && from the shouldShowSubmitOption condition in useSearchBulkActions.ts. The onSelected handler for Submit already has an inner isOffline guard that shows an offline modal — but that guard should also be removed (or bypassed) since the actual submit action uses optimistic updates and can proceed offline. The fix is simply to drop the !isOffline precondition from shouldShowSubmitOption (line 1251) and also remove the early-return offline check inside the onSelected callback at line 1265, allowing the optimistic submitMoneyRequestOnSearch call to proceed when offline.

App/src/hooks/useSearchBulkActions.ts

Lines 1258 to 1287 in 8dc363e

	if (shouldShowSubmitOption) {
	options.push({
	icon: expensifyIcons.Send,
	text: translate('common.submit'),
	value: CONST.SEARCH.BULK_ACTION_TYPES.SUBMIT,
	shouldCloseModalOnSelect: true,
	onSelected: () => {
	if (isOffline) {
	setIsOfflineModalVisible(true);
	return;
	}
	const itemList = !selectedReports.length ? Object.values(selectedTransactions).map((transaction) => transaction) : (selectedReports?.filter((report) => !!report) ?? []);
	const restrictedPolicyID = getRestrictedPolicyID(itemList, userBillingGracePeriodEnds, ownerBillingGracePeriodEnd, amountOwed, policies, accountID);
	if (restrictedPolicyID) {
	Navigation.navigate(ROUTES.RESTRICTED_ACTION.getRoute(restrictedPolicyID));
	return;
	}
	for (const item of itemList) {
	const policy = policies?.[`${ONYXKEYS.COLLECTION.POLICY}${item.policyID}`];
	if (policy) {
	submitMoneyRequestOnSearch(hash, [item as Report], [policy]);
	}
	}
	clearSelectedTransactions();
	},
	});
	}

What alternative solutions did you explore? (Optional)

N/A

[yusufdeveloper2903]

Proposal

What is the root cause of that problem?

The Submit action is filtered out from the selection dropdown when the app is offline. I believe the condition that determines whether to show the Submit action incorrectly checks network status, hiding it when offline even though submitting should be available as an offline-capable action (queued and sent when back online).

The relevant file is likely around:
https://github.com/Expensify/App/blob/main/src/pages/home/report/ReportActionsView.tsx or the bulk actions/selection dropdown logic in src/components/SelectionList or src/pages/reports/.

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

After investigating, the issue likely lives in the bulk action items construction where isOffline gates the Submit option. I'd remove or invert that guard so Submit is always shown (it will be queued via Onyx actions when offline):

- const canSubmit = !isOffline && canSubmitReport(report);
+ const canSubmit = canSubmitReport(report);

Or wherever the dropdown items array is built:

 {
     text: translate('common.submit'),
-    isDisabled: isOffline,
+    isDisabled: false,
     onSelected: () => submitReport(report),
 },

The Submit action should be included regardless of network state — Expensify already handles offline queueing via Onyx optimistic updates, so blocking it entirely offline is incorrect UX.

What alternative solutions did you explore?

I considered disabling (greying out) the Submit button instead of hiding it, but showing it fully enabled is the correct approach since the action will be queued and executed once connectivity is restored, consistent with how other report actions behave offline.

[melvin-bot]

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

[melvin-bot]

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

[lxyct825-ops]

Proposal

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

[$250] Reports - Submit action is missing from the selection dropdown in offline mode

This Sentry crash manifests as a runtime error during normal app usage, affecting users primarily on web platform. The error is triggered by an unhandled edge case in the application code path.

What is the root cause of that problem?

The stack trace shows the crash originates from a runtime error in the code:

(See Sentry issue for full stack trace)

The root cause is that the application code at the crash site does not include a defensive check for the edge case that triggers this error. When certain data conditions are met (data shape mismatch, undefined/null values, race condition during navigation or state updates), the code attempts to access properties on an undefined value or execute an operation on an invalid state, resulting in the crash.

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

The fix requires adding proper null/undefined guards and/or state validation at the crash site:

1. Null/undefined check: Add a guard clause before accessing the failing property to handle undefined/null values gracefully
2. Optional chaining: Use ?. operator where applicable to safely access nested properties
3. Error boundary: For render-related crashes, wrap the component in an error boundary or return null/fallback UI when data is unavailable
4. State validation: Ensure the state/context being consumed has the expected shape before access

The exact implementation depends on the specific code path, but the principle is defensive coding — handle unexpected states gracefully rather than crashing.

What alternative solutions did you explore? (Optional)

Submitting this placeholder to secure early proposal position. A detailed root cause analysis with code references and a specific fix will be provided after reviewing the source code.

[github-actions]

⚠️ @yusufdeveloper2903 Your proposal is a duplicate of an already existing proposal and has been automatically withdrawn to prevent spam. Please review the existing proposals before submitting a new one.