[Due for payment 2026-07-30] [$250] Expense-"Unexpected error" if submitting expense to new workspace via "Submit to my empoyer"

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

Action Performed:

Prerequisite: Use an expensifail account.
Prerequisite 2: Account has no workspaces and has Self DM.

1. Open the Expensify app.
2. Create a manual expense and submit it to Self DM.
3. Tap on "Submit to my employer"
4. Complete creation flow and submit expense.
5. Once you land on chat, tap on back button on the top left corner to return to "Inbox"
6. Reopen workspace chat.
7. After skeleton loader disappears, note that "Unexpected error creating this expense" message appears on expense preview.

Expected Result:

User should be able to create a new worksapce via "Submit to my employer" option and submit an expense to it.

Actual Result:

After creating a new workspace via "Submit to my employer" option and submitting an expense, an "Unexpected error" message appears on the just submitted expense.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7208337_1784051162593.Submit_it_5.mp4

View all open jobs on GitHub

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

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022077107988272184129
• Upwork Job ID: 2077107988272184129
• Last Price Increase: 2026-07-14

Issue Owner

Current Issue Owner: @abzokhattab

[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/7b8dd056b83b68feb9faff7981a50097aa7c6aceda2c127a6728952fb5e49430

[MelvinBot]

Issue Analysis

Root Cause (mechanism confirmed): The "Unexpected error" banner on the expense preview is iou.error.genericCreateFailureMessage ("Unexpected error submitting this expense…", en.ts:1589). It is written by the failureData of the single API call that the new "Submit to my employer" (0-workspace) flow makes — AddTrackedExpenseToPolicy (a backend alias of CategorizeTrackedExpense), which is supposed to create the submit2026 workspace and submit the expense atomically. Because it's failureData, the error is applied only when the backend returns a failure — which is why it doesn't show at submit time but appears on the preview after you reopen the chat and the skeleton loader resolves (i.e. after the server round-trip / re-fetch).

This flow was introduced yesterday in #94319, so this is a regression from that PR.

What needs confirming: Why the backend rejects AddTrackedExpenseToPolicy for a freshly-created draft submit2026 workspace. I could not query production logs in this run, so the exact jsonCode/error is unconfirmed. The likely fix lives in the backend handling of this command (or in the params the App sends for the new type: submit2026 create-and-submit path) — this needs an internal engineer with log + backend access to confirm before a fix is written.

Recommended next step: Pull the backend logs for AddTrackedExpenseToPolicy / CategorizeTrackedExpense for tester applausetester+ib0024@applause.expensifail.com around 2026-07-14 and read the returned jsonCode/error. That determines whether the fix is backend (command rejects the new submit-workspace create) or App-side (bad/missing params).

Related: #96117 ("Returning from 'Submit to my employer' if no workspace, leads to infinite loading") is the same new flow from the same PR — likely worth handling together.

Investigation details & evidence

Repro path (0 workspaces → "Submit to my employer"):

1. Routing: createDraftTransactionAndNavigateToParticipantSelector → with filteredPoliciesCount === 0 calls createDraftWorkspaceAndNavigateToConfirmationScreen, which creates a draft workspace (POLICY_DRAFTS/REPORT_DRAFT only, no API call) and sets the transaction's participant/report to that draft expenseChatReportID.
2. Submit dispatch: useExpenseSubmission.ts:1002-1027 detects action=SUBMIT && isDraftPolicy && policy.type=submit2026 and deliberately routes through trackExpense (not requestMoney) so the workspace can be created and the expense submitted in one command.
3. trackExpense re-builds the workspace optimistically via buildPolicyData, then fires AddTrackedExpenseToPolicy.

Where the error is attached (failureData): TrackExpense.ts:556-558 sets errors = getMicroSecondOnyxErrorWithTranslationKey('iou.error.genericCreateFailureMessage') on the IOU report action. The preview renders it via getUniqueActionErrorsForTransaction → RBRMessage in TransactionPreviewContent.tsx.

Ruled out: An earlier hypothesis was that the draft build and the submit build generate divergent policyID/expenseChatReportID. That is not the case — buildPolicyData reuses the draft policyID (policy?.id) and passes expenseReportId: chatReport?.reportID into buildOptimisticWorkspaceChats as optimisticReportID, so the expense chat report ID is preserved. (The admins-chat and CREATED-action IDs are regenerated in the second build, which is a lower-probability suspect worth a glance but not the confirmed cause.)

Confidence: Medium — the error mechanism (failureData from a failed AddTrackedExpenseToPolicy) is confirmed in code; the underlying backend rejection reason is unconfirmed pending logs.

---

Next Steps: An internal engineer should pull the AddTrackedExpenseToPolicy logs to confirm the backend error, then decide whether the fix is backend or App-side. Reply with @MelvinBot <feedback> to refine this analysis.

[yusufdeveloper2903]

Proposal

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

When a user with no workspaces uses "Submit to my employer" on a Self-DM tracked expense, we create a new Submit (submit2026) workspace and move the expense into it. After the flow finishes and the workspace chat is reopened, the expense preview shows a red "Unexpected error" brick-road, even though the submit appeared to succeed.

What is the root cause of that problem?

"Submit to my employer" with no existing workspace is routed — as of PR #92704 (commit f4e78cba284, "Route 'Submit to my employer' through AddTrackedExpenseToPolicy") — through trackExpense → submitTrackedExpenseToPolicy, so the workspace is created and the expense submitted in a single AddTrackedExpenseToPolicy request. The routing decision lives in useExpenseSubmission.ts:978-1008 (isSubmittingExpenseToDraftWorkspace), and the write goes through the shared moveTrackedExpenseToPolicy.

The optimistic data for this path comes from getTrackExpenseInformation. Because we're moving into a policy expense chat, shouldUseMoneyReport is true, so we optimistically build a brand-new expense report, IOU action and report-preview inside the just-created workspace. Its failure branch then stamps errors directly onto those optimistic actions — TrackExpense.ts:535-567 sets createChat: genericCreateReportFailureMessage on the expense report's errorFields and genericCreateFailureMessage on the IOU action — but it never deletes the optimistic expense report / preview it created.

The sibling flow already knows this is dangerous. When ConvertTrackedExpenseToRequest moves a tracked expense into a workspace, it explicitly appends getConvertTrackedExpenseWorkspaceFailureData to its failure data, with the comment "Removing the ghost IOU report on API failure which can cause unexpected errors" — see the call site at TrackExpense.ts:1552-1567. That helper SETs the optimistic IOU report to null, restores the report-preview, moves the transaction back to the Self-DM tracked-expense report, and re-attaches the error to the original tracked expense — so a failed move reverts cleanly.

moveTrackedExpenseToPolicy never calls that cleanup. So when the AddTrackedExpenseToPolicy write fails, the failure data leaves the optimistically-created expense report + preview sitting inside the new workspace, now carrying genericCreateFailureMessage. This is why the error only appears after the skeleton loader on reopen: the first render shows the still-optimistic (green) data; once OpenReport for the workspace chat resolves and the failure-mutated Onyx state is rendered, the ghost expense with its stuck error surfaces on the preview.

History of how we got here:

• Categorize/Share moves have long shared this same body, but they only ever succeeded against an already-valid workspace, so the missing rollback stayed dormant.
• PR #92704 (commit f4e78cba284) added the SUBMIT case that both creates a new workspace and submits in one AddTrackedExpenseToPolicy write — the first move-to-policy path where the request can realistically fail, exposing the absent ghost-report cleanup as a persistent, user-visible "Unexpected error".

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

Primary fix (root cause): make the move-to-policy failure data symmetric with the convert path — when a workspace was created as part of the move, append getConvertTrackedExpenseWorkspaceFailureData so a failed submit rolls the ghost expense out of the new workspace instead of leaving it stuck. Everything it needs is already on reportInformation + modifiedExpenseReportActionID inside moveTrackedExpenseToPolicy:

// In moveTrackedExpenseToPolicy, after getConvertTrackedExpenseInformation
// pushes its failure data, and only when this move created a workspace:
if (createdWorkspaceParams) {
    failureData?.push(
        ...getConvertTrackedExpenseWorkspaceFailureData({
            iouReportID: reportInformation.moneyRequestReportID,
            iouCreatedReportActionID: reportInformation.moneyRequestCreatedReportActionID,
            iouReportActionID: reportInformation.moneyRequestPreviewReportActionID,
            chatReportID: reportInformation.chatReportID,
            chatPreviewReportActionID: reportInformation.reportPreviewReportActionID,
            transactionID,
            linkedTrackedExpenseReportID: reportInformation.linkedTrackedExpenseReportID,
            linkedTrackedExpenseReportActionID: reportInformation.linkedTrackedExpenseReportAction?.reportActionID,
            transactionThreadReportID: reportInformation.transactionThreadReportID,
            modifiedExpenseReportActionID,
        }),
    );
}

Why this fixes it:

• Submit fails → reopen workspace chat: the optimistic expense report inside the new workspace is SET to null, the transaction is moved back to the Self-DM tracked-expense report (status: POSTED), and the error is re-attached to the original tracked expense. Reopening the workspace chat now shows no ghost expense and no stuck brick-road — matching how a failed ConvertTrackedExpenseToRequest already behaves.
• Submit succeeds: failure data never runs, so behavior is unchanged.
• Categorize/Share: guarded by if (createdWorkspaceParams), so only the create-a-workspace move gains the rollback; existing move-into-existing-workspace behavior is untouched.

Additional fix: since QA reproduces the error 100%, the AddTrackedExpenseToPolicy write itself is failing deterministically for the create-workspace-and-submit variant — the ghost cleanup makes the failure recoverable and non-confusing, but we should also confirm the request the App sends is one the backend accepts for a submit2026 workspace (i.e. that the type/policyName/admin-chat params forwarded by submitTrackedExpenseToPolicy produce a valid submitted expense report). If the write is expected to succeed, that is a complementary backend-parity check; the client-side defect that turns it into a stuck error is the missing rollback above.

Result: a failed "Submit to my employer" reverts cleanly to the Self-DM tracked expense (error shown there, retryable) instead of leaving an un-clearable "Unexpected error" expense inside the newly created workspace.

What alternative solutions did you explore? (Optional)

• Suppress/clear the error on the workspace expense preview. Hiding the brick-road treats the symptom, not the cause — the transaction would still be stranded in a workspace it never successfully landed in, and the user would have no path to retry. Rolling the move back is strictly better because it restores a consistent, retryable state.
• Null out the optimistic expense report inline in getTrackExpenseInformation's failure branch. This duplicates logic we already have and would also affect the plain track-create path that has no workspace to clean up. Reusing the purpose-built getConvertTrackedExpenseWorkspaceFailureData — the exact helper the convert path relies on — keeps both move flows converging on one rollback implementation.
• Only add error-cleanup on the report preview action. That leaves the orphaned optimistic expense report and the transaction pointing at the failed workspace, so the preview reappears on the next OpenReport. The failure only stops recurring once the ghost report is actually removed, which is what the primary fix does.

[aswin-s]

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

On Android, when an expensifail user with no workspaces creates a manual expense in Self DM, taps "Submit to my employer", completes the creation flow, and then returns to the Inbox and reopens the newly-created workspace chat, the expense preview shows "Unexpected error creating this expense". Expected: the expense should appear cleanly in the new Submit workspace with no red-brick-road error.

What is the root cause of that problem?

The "Submit to my employer" zero-workspace branch lives in createDraftTransactionAndNavigateToParticipantSelector in src/libs/ReportUtils.ts. When filteredPoliciesCount === 0 and submitDestination === CONST.IOU.SUBMIT_DESTINATION.EMPLOYER, the function calls createDraftWorkspaceAndNavigateToConfirmationScreen (lines 11565–11577) to spin up a new Submit workspace and navigate the transaction through the confirmation screen.

The problem originates one step earlier, in the same function, where the draft transaction is assembled and written to Onyx:

src/libs/ReportUtils.ts, lines ~11468–11484 (createDraftTransaction call)

createDraftTransaction({
    ...transaction,
    ...
    merchant,
    modifiedMerchant: '',   // <-- resets any modifiedMerchant to empty string
    isMerchantSet: !!isMerchantValid,
    ...
} as Transaction);

Setting modifiedMerchant: '' is intentional for the normal track-expense categorize/share flow, but it creates a problem for the "Submit to my employer" path. When the transaction later lands on an EXPENSE-type report inside the new Submit workspace, isMerchantMissing in src/libs/TransactionUtils/index.ts evaluates modifiedMerchant first. An empty string ('') is considered an invalid sentinel by isInvalidMerchantValue (which treats '', PARTIAL_TRANSACTION_MERCHANT, and DEFAULT_MERCHANT as invalid), so the check falls through to the raw merchant field. If the Self-DM manual expense had no merchant set, or carried PARTIAL_TRANSACTION_MERCHANT / DEFAULT_MERCHANT, then isMerchantMissing returns true.

This feeds into areRequiredFieldsEmpty at src/libs/TransactionUtils/index.ts:573-575 via the isFromExpenseReport && isMerchantMissing(transaction) guard, which makes hasMissingSmartscanFields true (line 1625–1626), which ultimately flows through hasSmartscanError → getAllReportActionsErrorsAndReportActionThatRequiresAttention at src/libs/ReportUtils.ts:9409-9412 and attaches the iou.error.genericSmartscanFailureMessage red-brick-road error to the report preview.

The error only surfaces after the user navigates away and back because the RBR/preview recomputes against the persisted transaction once the confirmation-flow local state is torn down.

Note: the createDraftWorkspaceAndNavigateToConfirmationScreen call itself correctly sets participants, assigns the report ID, and navigates to MONEY_REQUEST_STEP_CONFIRMATION — the confirmation screen is not skipped. The bug is that the draft transaction written to Onyx before that call already has modifiedMerchant: '', and when the transaction is subsequently associated with the new EXPENSE-type report, the merchant validation fails.

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

1. Normalize modifiedMerchant before the draft transaction is persisted for the employer submit path. In src/libs/ReportUtils.ts, inside createDraftTransactionAndNavigateToParticipantSelector, check whether the action is SUBMIT with submitDestination === EMPLOYER before the createDraftTransaction call. If the original merchant value is also invalid (empty / partial / default sentinel), set it to CONST.TRANSACTION.PARTIAL_TRANSACTION_MERCHANT (the standard placeholder that isMerchantMissing accepts as "intentionally not set by the user" on non-expense-report contexts) rather than leaving both fields blank. The key change:

// src/libs/ReportUtils.ts — inside createDraftTransactionAndNavigateToParticipantSelector
// before the createDraftTransaction({...}) call (around line 11455)

const isSubmitToEmployer =
    actionName === CONST.IOU.ACTION.SUBMIT &&
    submitDestination === CONST.IOU.SUBMIT_DESTINATION.EMPLOYER;

// For the employer-submit path the transaction will be placed on an EXPENSE-type
// report, so merchant must survive the isFromExpenseReport && isMerchantMissing
// check. If the original merchant is also invalid, use the partial sentinel so
// isMerchantMissing treats it as "user hasn't provided one yet" rather than
// triggering a genericSmartscanFailureMessage RBR.
const normalizedMerchant =
    isSubmitToEmployer && !isMerchantValid
        ? CONST.TRANSACTION.PARTIAL_TRANSACTION_MERCHANT
        : merchant;

createDraftTransaction({
    ...transaction,
    ...
    merchant: normalizedMerchant,
    modifiedMerchant: '',
    isMerchantSet: isSubmitToEmployer ? false : !!isMerchantValid,
    ...
} as Transaction);

2. In the confirmation screen for the new Submit workspace, ensure the required-fields validation runs against the draft policy's requiresCategory / requiresMerchant settings. createDraftWorkspace sets requiresCategory: true on the new workspace (it may also inherit requiresMerchant). The confirmation hook (useExpenseSubmission) should surface the missing-merchant field inline at confirmation time rather than allowing a merchant-less transaction to be persisted onto the expense report. If the confirmation screen already does this for the "exactly one workspace" path (line 11584 — setMoneyRequestParticipantsFromReport), verify that the zero-workspace draft path triggers the same inline validation at IOURequestStepConfirmation.

3. Defensive guard in areRequiredFieldsEmpty (src/libs/TransactionUtils/index.ts:573-575): when the transaction has a linkedTrackedExpenseReportID set (indicating it originated as a Self-DM track expense that was redirected to an expense report rather than submitted natively), treat the merchant requirement with the same leniency as a non-expense-report context until the user explicitly confirms the expense on the new workspace. This is a belt-and-suspenders change that prevents the RBR from firing if a future code path again persists a merchant-less transaction onto an EXPENSE-type report during the redirect flow.

4. Add a regression test that reproduces the 0-workspace "Submit to my employer" flow end-to-end and asserts that the resulting report preview has no errors.smartscan / errors.dewSubmitFailed entry after re-entering the chat.

What alternative solutions did you explore? (Optional)

An alternative is to strip the genericSmartscanFailureMessage path from the failure data generated by getConvertTrackedExpenseWorkspaceFailureData (called during the workspace-creation API response) for the case where the transaction is being moved from Self DM to a brand-new Submit workspace. However, this masks the symptom rather than fixing the underlying invalid-merchant state, so it would hide genuine scan errors in future code paths that share the same failure data builder. The normalization approach in change (1) above addresses the root cause directly and is the preferred fix.

[dilshodmackbook-sketch]

🚨 Edited by proposal-police: This proposal was edited at 2026-07-14 19:25:09 UTC.

Proposal

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

Submitting a tracked Self DM expense via "Submit to my employer" when the account has no workspaces shows "Unexpected error submitting this expense" on the expense preview after the workspace chat is reopened, even though the flow appeared to complete.

What is the root cause of that problem?

When the account has no workspace, "Submit to my employer" only creates a draft policy (it lives in POLICY_DRAFTS, nothing exists server-side yet). PR #94319 routes this case through submitTrackedExpenseToPolicy, which sends AddTrackedExpenseToPolicy with the workspace-creation params (policyName, type: submit2026, policyExpenseChatReportID, guidedSetupData, ...) so the backend creates the workspace and moves the expense in one request. That routing is gated in useExpenseSubmission:

App/src/pages/iou/request/step/confirmation/useExpenseSubmission.ts

Line 1002 in be9be33

const isSubmittingExpenseToDraftWorkspace = action === CONST.IOU.ACTION.SUBMIT && isDraftPolicy && policy?.type === CONST.POLICY.TYPE.SUBMIT;

The gate needs policy to resolve to the draft policy. But policy comes from usePolicyForTransaction, and for an unreported expense it never looks at policyDraft:

App/src/hooks/usePolicyForTransaction.ts

Lines 49 to 50 in be9be33

	const policyForSelfDMExpense = isPerDiemRequest ? customUnitPolicy : policyForMovingExpenses;
	const policy = isUnreportedExpense || isCreatingTrackExpense ? policyForSelfDMExpense : (reportPolicy ?? policyDraft);

A tracked expense being moved is always unreported — tracked Self DM expenses are built with reportID: CONST.REPORT.UNREPORTED_REPORT_ID:

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

Line 1087 in be9be33

reportID: shouldUseMoneyReport && iouReport ? iouReport.reportID : CONST.REPORT.UNREPORTED_REPORT_ID,

and createDraftTransactionAndNavigateToParticipantSelector copies that reportID into the draft transaction the confirmation page reads. So isUnreportedExpense is true, the hook returns policyForMovingExpenses — which scans only the real POLICY collection and can never return a draft — and with zero workspaces that is undefined. As a result isDraftPolicy (policy === policyDraft) is false, the gate fails, and the policyDraft that PR #94319 forwards into the hook is dead code for exactly the flow it was added for. The comment above it even describes what happens next:

App/src/pages/iou/request/step/IOURequestStepConfirmation.tsx

Lines 192 to 195 in be9be33

	// Forward the draft policy so a freshly created draft workspace (e.g. "Submit to my employer" with no existing
	// workspace) resolves here. Without it `policy` is undefined for drafts, `isDraftPolicy` is false, and the submit
	// is routed to ConvertTrackedExpenseToRequest (which needs a real payer) instead of AddTrackedExpenseToPolicy.
	policyDraft,

The submit falls through to requestMoney → convertTrackedExpenseToRequest, which sends the legacy AddTrackedExpenseToPolicy request built here:

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

Lines 1552 to 1591 in be9be33

	if (workspaceParams) {
	const additionalFailureData = getConvertTrackedExpenseWorkspaceFailureData({
	iouReportID: iouParams.reportID,
	iouCreatedReportActionID: iouParams.createdReportActionID,
	iouReportActionID: iouParams.reportActionID,
	chatReportID: chatParams.reportID,
	chatPreviewReportActionID: chatParams.reportPreviewReportActionID,
	transactionID,
	linkedTrackedExpenseReportID,
	linkedTrackedExpenseReportActionID: linkedTrackedExpenseReportAction.reportActionID,
	transactionThreadReportID,
	modifiedExpenseReportActionID: convertTrackedExpenseInformation.modifiedExpenseReportActionID,
	});
	// Removing the ghost IOU report on API failure which can cause unexpected errors.
	failureData?.push(...additionalFailureData);
	const workspaceParamsForAPI = hasManualDistanceOverrideForRequest ? {...workspaceParams, waypoints: undefined} : workspaceParams;
	const params = {
	amount,
	distance,
	currency,
	comment,
	created,
	merchant,
	attendees: attendees ? JSON.stringify(attendees) : undefined,
	reimbursable: true,
	transactionID,
	actionableWhisperReportActionID,
	moneyRequestReportID: iouParams.reportID,
	moneyRequestCreatedReportActionID: iouParams.createdReportActionID,
	moneyRequestPreviewReportActionID: iouParams.reportActionID,
	modifiedExpenseReportActionID: convertTrackedExpenseInformation.modifiedExpenseReportActionID,
	reportPreviewReportActionID: chatParams.reportPreviewReportActionID,
	shouldDeferAutoSubmit,
	...workspaceParamsForAPI,
	};
	addTrackedExpenseToPolicy(params, {optimisticData, successData, failureData});
	return;

This request carries only policyID — the draft policy ID — and none of the workspace-creation params. The backend has no policy with that ID, the command fails, and the failureData stamps iou.error.genericCreateFailureMessage onto the expense. The error only becomes visible after going back and reopening the chat because the failing response lands several seconds after the user is already sitting on the optimistically rendered chat (in the QA video the skeleton on reopen is the queued OpenReport waiting behind that failing request), which is also why the PR's own test videos looked fine — they end before the response arrives.

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

Let the draft policy resolve in usePolicyForTransaction when the moving-expenses lookup finds nothing, so the unreported (tracked) branch can see the freshly created draft workspace:

const policyForSelfDMExpense = isPerDiemRequest ? customUnitPolicy : policyForMovingExpenses;
const policy = isUnreportedExpense || isCreatingTrackExpense ? (policyForSelfDMExpense ?? policyDraft) : (reportPolicy ?? policyDraft);

With this, policy is the draft submit2026 policy, isDraftPolicy becomes true, the isSubmittingExpenseToDraftWorkspace gate passes, and the submit goes through submitTrackedExpenseToPolicy → AddTrackedExpenseToPolicy with the full createdWorkspaceParams — the atomic create-workspace-and-submit path PR #94319 built. A real policy still wins whenever one resolves (?? fallback), so accounts with existing workspaces are untouched; the fallback only activates when a draft was created for the transaction. If we want to be extra conservative it can be scoped to action === CONST.IOU.ACTION.SUBMIT.

What specific scenarios should be covered in automated tests?

1. Tracked Self DM expense, account with no workspaces, "Submit to my employer": assert the API command written is AddTrackedExpenseToPolicy including the workspace-creation params (policyName, type: submit2026, policyExpenseChatReportID), not ConvertTrackedExpenseToRequest/the legacy param set.
2. After the mocked success response, no report action or transaction retains genericCreateFailureMessage errors and the expense lives in the new workspace's expense report.
3. Regression: submit to an existing workspace and the categorize-with-draft-workspace flow still route through their current commands.
4. usePolicyForTransaction returns the draft policy for an unreported transaction when no real policy qualifies, and still prefers the real policy when one exists.

What alternative solutions did you explore? (Optional)

• Fixing only the gate (e.g. computing isDraftPolicy from policyDraft directly in IOURequestStepConfirmation, or passing policy ?? policyDraft into useExpenseSubmission). This unblocks the routing, but every other consumer on the confirmation page (validation, footer flags, category resolution) would keep seeing policy: undefined for this flow, so fixing resolution at the source is more complete.
• Teaching the fallback convertTrackedExpenseToRequest path to attach createdWorkspaceParams when the policy is a draft. This duplicates what submitTrackedExpenseToPolicy already does and keeps two live code paths for the same operation, which is what allowed this regression in the first place.

[KJ21-ENG]

Proposal

What is the root cause of that problem?

PR #94319 introduced the zero-workspace branch for “Submit to my employer”. The confirmation hook identifies the resulting submit2026 draft policy and routes it through trackExpense() so that the workspace and expense can be created together.

App/src/pages/iou/request/step/confirmation/useExpenseSubmission.ts

Lines 998 to 1004 in be9be33

	// "Submit to my employer" with no existing workspace creates a draft Submit (submit2026) workspace. Route it
	// through trackExpense (AddTrackedExpenseToPolicy) so the workspace is created and the expense submitted
	// atomically, instead of requestMoney/ConvertTrackedExpenseToRequest which can't create a workspace.
	// Scoped to submit2026 drafts only so other (team/corporate) draft flows keep their existing behavior.
	const isSubmittingExpenseToDraftWorkspace = action === CONST.IOU.ACTION.SUBMIT && isDraftPolicy && policy?.type === CONST.POLICY.TYPE.SUBMIT;
	if (!isPerDiemRequest && (isTrackExpense || isCategorizingTrackExpense || isSharingTrackExpense || isSelfDMDestination || isSubmittingExpenseToDraftWorkspace)) {

That new path ultimately calls submitTrackedExpenseToPolicy(), which always selects AddTrackedExpenseToPolicy and adds draft-workspace creation fields such as policyName and type. This is the regression: the existing AddTrackedExpenseToPolicy path is defined for moving an expense to an already-existing workspace, while PR #94319 widened only the client TypeScript type and assumed that this command also supports the CategorizeTrackedExpense workspace-creation contract. When the draft-workspace request fails, the optimistic move is rolled back and the linked tracked-expense action receives the generic creation error shown in the issue.

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

Lines 1395 to 1455 in be9be33

	type AddTrackedExpenseToPolicyParam = {
	amount: number;
	currency: string;
	comment: string;
	created: string;
	merchant: string;
	transactionID: string;
	reimbursable: boolean;
	actionableWhisperReportActionID: string | undefined;
	moneyRequestReportID: string;
	reportPreviewReportActionID: string;
	modifiedExpenseReportActionID: string;
	moneyRequestCreatedReportActionID: string | undefined;
	moneyRequestPreviewReportActionID: string;
	distance: number | undefined;
	attendees: string | undefined;
	shouldDeferAutoSubmit?: boolean;
	} & ConvertTrackedWorkspaceParams;
	type ConvertTrackedExpenseToRequestParams = {
	payerParams: {
	accountID: number;
	email: string;
	};
	transactionParams: {
	transactionID: string;
	actionableWhisperReportActionID: string | undefined;
	linkedTrackedExpenseReportAction: OnyxTypes.ReportAction;
	linkedTrackedExpenseReportID: string;
	amount: number;
	currency: string;
	comment: string;
	merchant: string;
	created: string;
	attendees?: Attendee[];
	transactionThreadReportID?: string;
	distance?: number;
	isLinkedTrackedExpenseReportArchived: boolean | undefined;
	waypoints?: string;
	customUnitRateID?: string;
	isDistance?: boolean;
	};
	chatParams: {
	reportID: string;
	createdReportActionID: string | undefined;
	reportPreviewReportActionID: string;
	};
	iouParams: {
	reportID: string;
	createdReportActionID: string | undefined;
	reportActionID: string;
	};
	onyxData: OnyxData<BuildOnyxDataForMoneyRequestKeys>;
	workspaceParams?: ConvertTrackedWorkspaceParams;
	currentUserAccountID: number;
	shouldDeferAutoSubmit?: boolean;
	};
	function addTrackedExpenseToPolicy(parameters: AddTrackedExpenseToPolicyParam, onyxData: OnyxData<BuildOnyxDataForMoneyRequestKeys>) {
	API.write(WRITE_COMMANDS.ADD_TRACKED_EXPENSE_TO_POLICY, parameters, onyxData);
	}

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

Lines 2228 to 2250 in be9be33

	/**
	* Submit a tracked expense ("Submit to my employer") into a workspace. Uses AddTrackedExpenseToPolicy, which is a
	* backend alias of CategorizeTrackedExpense, so it can both create a Submit (submit2026) workspace from a draft and
	* move the tracked expense into it in a single request.
	*/
	function submitTrackedExpenseToPolicy(trackedExpenseParams: TrackedExpenseParams) {
	const {transactionParams, createdWorkspaceParams, isDistanceRequest} = trackedExpenseParams;
	moveTrackedExpenseToPolicy(trackedExpenseParams, {
	action: CONST.IOU.ACTION.SUBMIT,
	command: WRITE_COMMANDS.ADD_TRACKED_EXPENSE_TO_POLICY,
	extraParams: {
	// Forward the optimistic workspace name so the backend-created workspace matches what the user sees offline
	// (e.g. "Test's Workspace") instead of falling back to a backend-generated default.
	policyName: createdWorkspaceParams?.policyName,
	// Only forward the (new) workspace's distance custom unit for actual distance expenses. For a manual/scan expense,
	// sending them would tell the backend to treat the moved expense as a 0-mile distance request and wipe the amount.
	customUnitID: isDistanceRequest ? createdWorkspaceParams?.customUnitID : undefined,
	customUnitRateID: isDistanceRequest ? (createdWorkspaceParams?.customUnitRateID ?? transactionParams.customUnitRateID) : undefined,
	// Reached only for the submit2026 draft flow (gated in useExpenseSubmission and getTrackExpenseInformation), so a
	// workspace created here must be a Submit (submit2026) workspace.
	type: createdWorkspaceParams ? CONST.POLICY.TYPE.SUBMIT : undefined,
	},
	});

App/src/libs/API/parameters/AddTrackedExpenseToPolicyParams.ts

Lines 5 to 18 in be9be33

	import type CategorizeTrackedExpenseParams from './CategorizeTrackedExpenseParams';
	// AddTrackedExpenseToPolicy is a backend alias of CategorizeTrackedExpense, so it accepts the same
	// parameters (including the optional workspace-creation params used when moving a tracked expense into
	// a newly created draft workspace).
	type AddTrackedExpenseToPolicyParams = CategorizeTrackedExpenseParams & {
	reimbursable?: boolean;
	distance?: number;
	shouldDeferAutoSubmit?: boolean;
	/** Name to give the workspace when one is created as part of this request, so the backend matches the optimistic name. */
	policyName?: string;
	/** Policy type to create when a workspace is created as part of this request (e.g. submit2026 for "Submit to my employer"). */
	type?: ValueOf<typeof CONST.POLICY.TYPE>;
	};

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

Update submitTrackedExpenseToPolicy() to select CategorizeTrackedExpense when createdWorkspaceParams is present (the draft-policy case), while keeping AddTrackedExpenseToPolicy for a persisted workspace. Continue passing CONST.IOU.ACTION.SUBMIT to moveTrackedExpenseToPolicy() so the optimistic action is resolved as a submission, and keep the submit2026 type, employer engagement choice, generated workspace/report IDs, policy name, and distance-only custom-unit fields in the draft payload.

moveTrackedExpenseToPolicy() already accepts either command and centralizes the common optimistic/success/failure data. Its other caller, categorizeTrackedExpense(), must remain unchanged and continue using CategorizeTrackedExpense; the trackExpense() SUBMIT switch must also remain the single caller of submitTrackedExpenseToPolicy(). Thus the fix belongs in the submit wrapper's command selection, not in the shared API writer or the general confirmation routing.

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

Lines 2137 to 2225 in be9be33

	type MoveTrackedExpenseToPolicyConfig = {
	/** Tracked-expense action this move represents; drives getConvertTrackedExpenseInformation. */
	action: typeof CONST.IOU.ACTION.CATEGORIZE | typeof CONST.IOU.ACTION.SUBMIT;
	/** API command to write: CategorizeTrackedExpense or its AddTrackedExpenseToPolicy alias. */
	command: typeof WRITE_COMMANDS.CATEGORIZE_TRACKED_EXPENSE | typeof WRITE_COMMANDS.ADD_TRACKED_EXPENSE_TO_POLICY;
	/** Command-specific params merged over the shared ones (e.g. policyName/type for AddTrackedExpenseToPolicy, distance custom unit). */
	extraParams?: Partial<AddTrackedExpenseToPolicyParams>;
	};
	/**
	* Shared implementation for moving a tracked expense into a policy. categorizeTrackedExpense (CategorizeTrackedExpense)
	* and submitTrackedExpenseToPolicy (AddTrackedExpenseToPolicy, a backend alias) only differ by the action passed to
	* getConvertTrackedExpenseInformation, the write command, and a few command-specific params, so they share this body.
	*/
	function moveTrackedExpenseToPolicy(trackedExpenseParams: TrackedExpenseParams, {action, command, extraParams}: MoveTrackedExpenseToPolicyConfig) {
	const {onyxData, reportInformation, transactionParams, policyParams, createdWorkspaceParams, currentUser} = trackedExpenseParams;
	const {accountID: currentUserAccountID} = currentUser;
	const {optimisticData, successData, failureData} = onyxData ?? {};
	const {transactionID} = transactionParams;
	const {isDraftPolicy} = policyParams;
	const {
	actionableWhisperReportActionID,
	moneyRequestReportID,
	linkedTrackedExpenseReportAction,
	linkedTrackedExpenseReportID,
	transactionThreadReportID,
	isLinkedTrackedExpenseReportArchived,
	} = reportInformation;
	const {
	optimisticData: moveTransactionOptimisticData,
	successData: moveTransactionSuccessData,
	failureData: moveTransactionFailureData,
	modifiedExpenseReportActionID,
	} = getConvertTrackedExpenseInformation(
	transactionID,
	actionableWhisperReportActionID,
	moneyRequestReportID,
	linkedTrackedExpenseReportAction,
	linkedTrackedExpenseReportID,
	transactionThreadReportID,
	action,
	isLinkedTrackedExpenseReportArchived,
	currentUserAccountID,
	);
	optimisticData?.push(...moveTransactionOptimisticData);
	successData?.push(...moveTransactionSuccessData);
	failureData?.push(...moveTransactionFailureData);
	const parameters: AddTrackedExpenseToPolicyParams = {
	...{
	...reportInformation,
	linkedTrackedExpenseReportAction: undefined,
	},
	...policyParams,
	...transactionParams,
	modifiedExpenseReportActionID,
	policyExpenseChatReportID: createdWorkspaceParams?.expenseChatReportID,
	policyExpenseCreatedReportActionID: createdWorkspaceParams?.expenseCreatedReportActionID,
	adminsChatReportID: createdWorkspaceParams?.adminsChatReportID,
	adminsCreatedReportActionID: createdWorkspaceParams?.adminsCreatedReportActionID,
	engagementChoice: createdWorkspaceParams?.engagementChoice,
	guidedSetupData: createdWorkspaceParams?.guidedSetupData,
	description: transactionParams.comment,
	attendees: transactionParams.attendees ? JSON.stringify(transactionParams.attendees) : undefined,
	...extraParams,
	};
	API.write(command, parameters, {optimisticData, successData, failureData});
	// If a draft policy was used, the command will create a real one, so track that conversion here.
	if (isDraftPolicy) {
	const workspaceCreatedEvent = getWorkspaceCreatedAnalyticsEvent(createdWorkspaceParams?.engagementChoice, createdWorkspaceParams?.companySize, currentUser.email ?? '');
	GoogleTagManager.publishEvent(workspaceCreatedEvent, currentUserAccountID, currentUser.email ?? '');
	}
	}
	function categorizeTrackedExpense(trackedExpenseParams: TrackedExpenseParams) {
	const {transactionParams, createdWorkspaceParams} = trackedExpenseParams;
	moveTrackedExpenseToPolicy(trackedExpenseParams, {
	action: CONST.IOU.ACTION.CATEGORIZE,
	command: WRITE_COMMANDS.CATEGORIZE_TRACKED_EXPENSE,
	extraParams: {
	customUnitID: createdWorkspaceParams?.customUnitID,
	customUnitRateID: createdWorkspaceParams?.customUnitRateID ?? transactionParams.customUnitRateID,
	},
	});

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

Lines 2732 to 2755 in be9be33

	case CONST.IOU.ACTION.SUBMIT: {
	if (!linkedTrackedExpenseReportAction || !linkedTrackedExpenseReportID) {
	return;
	}
	const transactionParams: TrackedExpenseTransactionParams = {
	transactionID: transaction?.transactionID,
	amount,
	currency,
	comment,
	distance,
	merchant,
	created,
	taxCode,
	taxAmount,
	category,
	tag,
	billable,
	reimbursable,
	receipt: isFileUploadable(trackedReceipt) ? trackedReceipt : undefined,
	waypoints: sanitizedWaypoints,
	customUnitRateID: mileageRate,
	attendees,
	};
	const policyParams: TrackedExpensePolicyParams = {

Test coverage:

• Add a unit test around the submit wrapper/API write selection proving that a Submit draft with createdWorkspaceParams uses CategorizeTrackedExpense and includes the workspace-creation identifiers, type: submit2026, policyName, and employer engagement choice.
• Add a companion case proving that a persisted workspace still uses AddTrackedExpenseToPolicy, and ensure the existing categorize call remains on CategorizeTrackedExpense.
• Regression-test the reported flow from a self-DM with no workspaces, then leave and reopen the new workspace chat and verify the expense preview has no error.

What alternative solutions did you explore? (Optional)

I considered extending the backend AddTrackedExpenseToPolicy command to accept the complete draft-workspace creation contract. That would preserve PR #94319’s current command choice, but it requires a backend contract change and leaves the App depending on two nominally different commands for the same create-and-move operation. Selecting the already-established CategorizeTrackedExpense creation path in the App is smaller and keeps AddTrackedExpenseToPolicy scoped to its existing persisted-policy use.

[melvin-bot]

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