[$250] iOS - Distance - App become freeze after selecting a new domain user

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

Action Performed:

1. Open the iOS app and log in with applausetester+newmanualexpense3@applause.expensifail.com
2. Global + (FAB) → Track distance → Map tab → set Start and Stop addresses → Next.
3. Enter a brand‑new user email (a domain you have no existing chat with) → Create x.xx expense.

Expected Result:

Verify navigation goes to the chat with the new user and the expense is created there, with no "There is a previously existing chat between these users." error.

Actual Result:

App become freeze

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7201431_1783402882360.freeze.mp4

View all open jobs on GitHub

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

Upwork Automation - Do Not Edit

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

Issue Owner

Current Issue Owner: @thelullabyy

[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/6d3158ff1b9f72c757758cdb43776947588b816763e0fcd59dc79f738d26378b

[MelvinBot]

Proposal

⚠️ Medium confidence. The root-cause chain below is well-evidenced in code (file:line references), but the exact freeze mechanism (render loop vs. navigation hang toward a report that never resolves) was not provable from static reads alone — runtime logs would pin it down. See the note at the end.

This freeze was surfaced during QA of #94755 (merged 2026-07-03), which fixed the older "There is a previously existing chat between these users" error on this same flow. That fix removed the error but left the flow in an inconsistent state that now hangs.

What is the root cause of that problem?

PR #94755 made the confirmation page assign the transaction a fresh optimistic reportID for a brand‑new recipient — but that ID is never actually used to create a report, so the page ends up pointing at a report that never exists.

Concretely, there is a three‑way reportID mismatch:

1. When you pick a brand‑new user, handleParticipantsAdded flips iouType to CREATE and sets transaction.reportID to a freshly generated optimistic ID (call it A) — IOURequestStepConfirmation.tsx:344-358.
2. The page subscribes to the report at transaction.reportID (ID A) — IOURequestStepConfirmation.tsx:171-183. Nothing is ever written to Onyx at ID A, so the report resolves to undefined: resolveReportForMoneyRequest bails because the transaction's report differs from the route report — IOUUtils.ts:525-537. With report undefined and iouType now CREATE (not TRACK), destinationReportID is also undefined — IOURequestStepConfirmation.tsx:512-515.
3. On submit, createDistanceRequest does not pass ID A down as optimisticChatReportID, so the builder creates the optimistic chat at yet another random ID (B) — useExpenseSubmission.ts → buildOptimisticChatReport MoneyRequestBuilder.ts:1315-1327.

So the transaction points at A, the actual report is created at B, and the route still references the Workspace report. The confirmation page's subscription to A never resolves, and post‑create navigation targets B — the UI is left waiting on a report that never materializes at the ID it is watching, which is what hangs.

The legacy participant‑step path does not freeze because it keeps the ID coherent: the generated ID is written to transaction.reportID and carried through the route/navigation as the same ID — useParticipantSubmission.ts:297-303.

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

Keep the generated reportID coherent end‑to‑end, the same way the participant step already does. When the confirmation page generates a fresh optimistic reportID for a brand‑new recipient, that same ID must be the one the submit action uses to build the optimistic chat report — i.e. thread transaction.reportID into the distance‑create submission as the optimistic chat report ID so the report is actually created at the ID the page is subscribed to. That removes the A‑vs‑B mismatch, so the page's report resolves and navigation lands on the real chat.

Investigation details

• Full render tree, all useEffects, the submit orchestrator decision tree, and createDistanceRequest were traced; no hard synchronous infinite loop was found in statically-reachable code. The strongest re-fire candidate is the pre-insert useEffect at IOURequestStepConfirmation.tsx:518-602, but destinationReportID appears stably undefined, which argues against an oscillation there.
• The hang is therefore most likely a navigation / re-render effect waiting on a report at ID A that is never created (it's created at B instead).
• Logs would confirm the exact mechanism. On iOS v9.4.28-0 with NEW_MANUAL_EXPENSE_FLOW, around the "Create expense" tap, look for: React "Maximum update depth exceeded" from IOURequestStepConfirmation; repeated OpenReport / report-not-found / Navigation.navigate calls to a reportID with no report; or navigateAfterExpenseCreate / SubmitExpenseOrchestrator lines firing without a destinationReportID.

What alternative solutions did you explore? (Optional)

An alternative is to revert to landing on the correct report on submit rather than pre-binding a fresh optimistic ID on participant selection, but that risks reintroducing the "previously existing chat" error #94755 fixed. Keeping the IDs coherent is the smaller, safer change.

---

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

[nabi-ebrahimi]

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

Proposal

What is the root cause of that problem?

When the confirmation page replaces the auto-assigned workspace participant with a brand-new P2P participant, handleParticipantsAdded generates a fresh optimistic reportID and writes it to the transaction draft:

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

Lines 351 to 358 in 81ff15e

	// A brand-new recipient picked by email has no chat yet (no reportID). Reusing the route's `reportID`
	// (which points at the flow's origin report - e.g. the default workspace chat this distance flow was
	// seeded with) leaves the expense bound to that workspace, so the backend rejects it with
	// "There is a previously existing chat between these users." Generate a fresh optimistic reportID for
	// P2P recipients, mirroring the legacy participants-step flow (useParticipantSubmission).
	// eslint-disable-next-line @typescript-eslint/prefer-nullish-coalescing
	const participantReportID = firstParticipant.reportID || (isPolicyExpenseChatParticipant ? reportID : generateReportID());
	setTransactionReport(activeTransactionID, {reportID: participantReportID}, true);

That ID has no matching report in Onyx. After this write, resolveReportForMoneyRequest intentionally returns undefined because the transaction report ID is different from the route workspace report, and the generated transaction report cannot be resolved:

App/src/libs/IOUUtils.ts

Lines 525 to 537 in 81ff15e

	if (transaction?.reportID === CONST.REPORT.UNREPORTED_REPORT_ID) {
	return undefined;
	}
	const canUseTransactionReport = !(isProcessingReport(transactionReport) && !policy?.harvesting?.enabled) && isReportOutstanding(transactionReport, policy?.id, undefined, false);
	const shouldUseTransactionReport = !!transactionReport && (canUseTransactionReport || !routeReport);
	if (shouldUseTransactionReport) {
	return transactionReport;
	}
	const isTransactionReportDifferentFromRoute = !!transaction?.reportID && !!routeReport?.reportID && transaction.reportID !== routeReport.reportID;
	if (isTransactionReportDifferentFromRoute) {
	return undefined;
	}
	return routeReport;

So the confirmation screen also loses its destination report:

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

Lines 512 to 516 in 81ff15e

	const selfDMReportID = iouType === CONST.IOU.TYPE.TRACK ? findSelfDMReportID() : undefined;
	const isMRReport = isMoneyRequestReport(report);
	const destinationReportID =
	backToReport ?? (isPerDiemRequest && isMRReport && Navigation.getTopmostReportId() !== report?.reportID ? report?.chatReportID : report?.reportID) ?? selfDMReportID;
	const [destinationReport] = useOnyx(`${ONYXKEYS.COLLECTION.REPORT}${destinationReportID}`);

On submit, the distance path calls createDistanceRequest without passing this generated ID as optimisticChatReportID:

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

Lines 122 to 146 in 81ff15e

	type CreateDistanceRequestInformation = {
	report: OnyxEntry<OnyxTypes.Report>;
	participants: Participant[];
	currentUserLogin: string;
	currentUserAccountID: number;
	iouType?: ValueOf<typeof CONST.IOU.TYPE>;
	existingIOUReport?: OnyxEntry<OnyxTypes.Report>;
	existingTransaction?: OnyxEntry<OnyxTypes.Transaction>;
	transactionParams: DistanceRequestTransactionParams;
	policyParams?: BasePolicyParams;
	isASAPSubmitBetaEnabled: boolean;
	transactionViolations: OnyxCollection<OnyxTypes.TransactionViolation[]>;
	quickAction: OnyxEntry<OnyxTypes.QuickAction>;
	policyRecentlyUsedCurrencies: string[];
	recentWaypoints: OnyxEntry<OnyxTypes.RecentWaypoint[]>;
	customUnitPolicyID?: string;
	shouldPlaySound?: boolean;
	personalDetails: OnyxEntry<OnyxTypes.PersonalDetailsList>;
	betas: OnyxEntry<OnyxTypes.Beta[]>;
	optimisticReportPreviewActionID?: string;
	shouldDeferAutoSubmit?: boolean;
	previousOdometerDraft?: OnyxEntry<OnyxTypes.OdometerDraft>;
	// TODO: delegateAccountID will be made required in PR 10 when all callers pass the value (https://github.com/Expensify/App/issues/66425)
	delegateAccountID?: number | undefined;
	};

But the money request builder only reuses a caller-provided optimistic chat report ID when it receives one:

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

Lines 1221 to 1227 in 81ff15e

	moneyRequestReportID = '',
	retryParams,
	newReportTotal,
	newNonReimbursableTotal,
	testDriveCommentReportActionID,
	optimisticChatReportID,
	optimisticCreatedReportActionID,

As a result, the draft transaction points at generated report ID A, while createDistanceRequest creates the optimistic chat at a different generated report ID B. The confirmation screen, submit action, optimistic Onyx data, and navigation target no longer agree on the same chat report, which leaves the iOS flow stuck instead of landing in the newly created P2P chat.

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

Keep a single source of truth for the optimistic P2P chat report ID.

Extend CreateDistanceRequestInformation and createDistanceRequest to accept an optional optimisticChatReportID, then pass it through to getMoneyRequestInformation. That matches the existing builder contract: getMoneyRequestInformation already uses optimisticChatReportID when building a new optimistic chat report.

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

Lines 1319 to 1327 in 81ff15e

	// If we still don't have a report, it likely doesn't exist and we need to build an optimistic one
	if (!chatReport) {
	isNewChatReport = true;
	chatReport = buildOptimisticChatReport({
	participantList: [payerAccountID, payeeAccountID],
	optimisticReportID: optimisticChatReportID,
	currentUserAccountID: currentUserAccountIDParam,
	});
	}

Then, in useExpenseSubmission.createDistanceRequest, pass transaction.reportID as optimisticChatReportID only for the narrow brand-new P2P case:

• the selected participant is not a policy expense chat
• the selected participant has no existing reportID
• report is undefined because the generated transaction report is not loaded
• transaction.reportID is a real generated ID, not CONST.REPORT.UNREPORTED_REPORT_ID

Do not pass this value for existing chats, policy expense chats, self-DM/track fallback, or split flows.

Also make the confirmation destination derive from that same pending optimistic chat report ID for this specific brand-new P2P case. This keeps the submit orchestrator, post-submit cleanup, optimistic Onyx data, and navigation target pointed at the same report instead of treating the destination as missing.

Optionally, clean up the P2P distance-rate reset in handleParticipantsAdded: when the selected participant has no report and no policy, DistanceRequestUtils.getCustomUnitRateID() can only return CONST.CUSTOM_UNITS.FAKE_P2P_ID, so using the constant directly would avoid an unnecessary helper call. That is cleanup, not the root fix.

What alternative solutions did you explore? (Optional)

[shivang-goliyan]

🚨 Edited by proposal-police: This proposal was edited at 2026-07-07 07:04:43 UTC.

Proposal

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

On the distance flow, when you pick a brand-new recipient by email (someone you have no existing chat with) from the confirmation page and create the expense, the app freezes instead of landing on the new chat with the expense in it. This is the exact QA step from PR #94755, which fixed the earlier "There is a previously existing chat between these users" error on this same flow but left the flow in a broken state.

What is the root cause of that problem?

The confirmation page ends up subscribed to a report ID that never gets created in Onyx, so the created expense lands somewhere else and the page waits forever for a report that will never load.

In src/pages/iou/request/step/IOURequestStepConfirmation.tsx, handleParticipantsAdded (around lines 348-358, added by #94755) does this for a P2P recipient with no existing chat:

const participantReportID = firstParticipant.reportID || (isPolicyExpenseChatParticipant ? reportID : generateReportID()); // call it A
setTransactionReport(activeTransactionID, {reportID: participantReportID}, true);

That fresh ID A gets written onto the draft transaction only. Nothing is ever created in Onyx at A, and the route still points at the workspace chat the flow was seeded with. From there:

1. resolveReportForMoneyRequest (IOUUtils.ts:513-538) sees a transaction.reportID that differs from the route report and returns undefined, so there's no destination report.
2. On submit, createDistanceRequest (Split.ts:1911) never threads A through, so buildOptimisticChatReport mints a different ID B, and B is what actually gets written to Onyx and navigated to.

So the page is bound to A (which is never created), the real new chat is B, and the route is the workspace. Three IDs, none of them agreeing. The legacy participants-step path doesn't hit this because useParticipantSubmission generates the ID once and threads it through both the transaction and the submit action, so everything stays coherent. The new confirmation-page picker sets the ID on the transaction but updates neither the route nor the submit path.

One note on scope: the || generateReportID() with the eslint-disable is intentional (a falsy reportID needs to fall through), so that line isn't a ??-vs-|| bug. The bug is that the generated ID is orphaned, not how it's computed.

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

Create the optimistic chat at the same ID the page already subscribed to. Thread transaction.reportID (the A set in handleParticipantsAdded) into createDistanceRequest as the optimisticChatReportID, which is already honored downstream in MoneyRequestBuilder.ts. That makes B == A, so the report the page is waiting on is the one that actually gets created, the subscription resolves, and navigation lands on the real new-user chat.

I'd do this at the submit/action layer rather than patching the picker, so the ID stays coherent for any caller that reaches createDistanceRequest this way, not just this one entry point. There's no test today for picking a brand-new P2P recipient on the confirmation page (neither IOURequestStepConfirmationPageTest.tsx nor IOURequestStepDistanceTest.tsx covers it), so I'd add one asserting the created chat's reportID equals the transaction.reportID the page subscribed to.

Since the reported symptom is a runtime freeze, I want to confirm the exact hang on an iOS build before finalizing — the ID mismatch is clear from the code, but the freeze-vs-silent-misfire behavior should be verified on device.

What alternative solutions did you explore? (Optional)

Reverting #94755 would stop the freeze but bring back the original "previously existing chat between these users" error, so that's a step backwards. Keeping the generated ID in a ref and handing it to the submit path (instead of persisting it on the transaction) also works, but it's the same coherence fix done in a less central spot — reusing the existing optimisticChatReportID plumbing keeps the change smaller and matches how the rest of the money-request builder already threads report IDs.

[aswin-s]

Proposal

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

On iOS, when a user starts a Track distance expense (Global + → Track distance → Map tab → set Start/Stop → Next) and then enters a brand-new user email as recipient (a domain the tester has no existing chat with), the app freezes instead of navigating to the new chat and creating the expense there.

What is the root cause of that problem?

Regression from PR #94755. In src/pages/iou/request/step/IOURequestStepConfirmation.tsx the new handleParticipantsAdded P2P branch (lines 342–377) mutates the draft transaction in the same tick it reads it: for a Track-distance flow with a brand-new email, firstParticipant.reportID is undefined and isPolicyExpenseChatParticipant is false, so the code calls setTransactionReport(...) (line 358), then setCustomUnitRateID(activeTransactionID, p2pRateID, transaction, undefined, false, personalPolicy?.outputCurrency) (line 374) and setMoneyRequestCategory(...) (line 376). setCustomUnitRateID in src/libs/actions/IOU/MoneyRequest.ts:665 merges into TRANSACTION_DRAFT, which re-emits transaction — that is a dep of the participant-seeding useEffect at line 399/420 and of useFetchRoute (line 446). Because the new branch also flips iouType from TRACK to CREATE on line 344 without a matching guard, the seeding effect and the mileage-rate write keep alternating on the newly generated optimistic reportID (line 357), producing a re-render loop that freezes the UI on the confirmation step for the brand-new-user case.

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

1. src/pages/iou/request/step/IOURequestStepConfirmation.tsx line 365–377: guard the P2P defaults reset so it runs only once per participant change (e.g. compare current transaction?.comment?.customUnit?.customUnitRateID against p2pRateID and current transaction?.category before calling setCustomUnitRateID/setMoneyRequestCategory), so the draft merge does not re-fire the enclosing callback via the transaction dep.
2. src/pages/iou/request/step/IOURequestStepConfirmation.tsx line 384–396: drop transaction (or narrow to transaction?.transactionID) from the handleParticipantsAdded dep list — passing the whole transaction re-creates the callback on every draft merge triggered by the callback itself.
3. src/pages/iou/request/step/IOURequestStepConfirmation.tsx line 399–420: tighten the seeding effect so it early-returns once the transaction has a non-default reportID (the optimistic one generated on line 357), preventing it from re-seeding defaultParticipants after handleParticipantsAdded has already applied the new P2P participant.
4. src/pages/iou/request/step/IOURequestStepConfirmation.tsx line 357: only call generateReportID() when iouType transitioned from TRACK/SUBMIT to CREATE on this invocation — reusing a fresh optimistic id on every re-render is what compounds with (1)/(2) to lock the loop on iOS.
5. Add a regression test that drives handleParticipantsAdded with a brand-new (no reportID) P2P participant on a Track-distance transaction and asserts setCustomUnitRateID is invoked at most once.

What alternative solutions did you explore? (Optional)

[ahmdshrif]

Proposal

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

On iOS, in the new-manual-expense distance flow (global create → Track distance → set waypoints → Next), selecting a brand-new user (no existing chat) on the confirmation step freezes the app.

What is the root cause of that problem?

This is a regression from PR #94755 (the issue this bug was filed against in PR QA). That PR changed handleParticipantsAdded so that when the selected recipient has no existing chat, it immediately writes a freshly generated optimistic reportID into the draft transaction:

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

Lines 357 to 358 in 3fa730e

	const participantReportID = firstParticipant.reportID || (isPolicyExpenseChatParticipant ? reportID : generateReportID());
	setTransactionReport(activeTransactionID, {reportID: participantReportID}, true);

No report with that ID exists in Onyx, so the confirmation screen is now bound to a phantom report. The legacy participants-step flow that PR #94755 says it mirrors deliberately does NOT do this — it keeps the generated ID in a ref (selectedReportID.current) and only uses it at submit time, so the confirmation screen never observes a reportID with no backing report:

App/src/hooks/useParticipantSubmission.ts

Line 303 in 3fa730e

selectedReportID.current = firstParticipantReportID || generateReportID();

With the phantom reportID persisted, the screen's report-driven effects re-fire against a report that never loads. In particular the narrow-layout (mobile-only, hence iOS) pre-insert effect explicitly documents that its no-oscillation safety rests on setTransactionReport firing only once during resetIOUTypeIfChanged — an invariant PR #94755 broke by adding a second setTransactionReport call in the selection handler:

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

Lines 595 to 601 in 3fa730e

	// The hasPreInsertFired reset enables at most one additional re-fire when
	// destinationReportID transitions from undefined to a valid ID. If destinationReportID
	// were to change from one valid ID to another (extremely unlikely with Onyx), the
	// pre-insert would re-fire once more, which is acceptable since the cleanup removes the
	// stale route first. Oscillation is not possible because setTransactionReport only fires
	// once during resetIOUTypeIfChanged.
	// eslint-disable-next-line react-hooks/exhaustive-deps

The pre-insert/teardown cycle plus the transaction-dependent distance-rate effects (which the same handler also retriggers via setCustomUnitRateID/setMoneyRequestCategory at L367-L376) keep mutating the draft and re-rendering, and the JS thread never settles — the app freezes.

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

Mirror the legacy flow's contract: do not persist a bare generated reportID into the draft transaction at selection time. In handleParticipantsAdded (IOURequestStepConfirmation.tsx#L357-L358), for a P2P recipient with no existing chat, either:

• keep the transaction unbound (leave reportID unset / UNREPORTED_REPORT_ID) and let the submit path (createDistanceRequest/requestMoney) generate the optimistic chat reportID at confirm time, exactly as useParticipantSubmission.ts#L303 does via its ref; or
• if the ID must be assigned at selection, create the optimistic chat report draft in Onyx first (buildOptimisticChatReport + draft write) before calling setTransactionReport, so the reportID always has a backing report and the screen's effects settle.

The first option is minimal and restores the invariant the pre-insert effect depends on. Regression check: re-run the PR #94755 QA case (distance expense to new user must land in the new chat without the "previously existing chat" error) plus an existing-chat recipient and a workspace recipient, verifying no freeze and no duplicate confirmation-screen re-renders.

[samranahm]

Proposal

What is the root cause of that problem?

In the Track distance flow, after setting the map addresses and pressing Next, the user lands on the participants selector step. Entering a brand new domain user (one with no existing chat) causes the app to freeze on iOS.

The participant selection step for money requests is IOURequestStepParticipants.tsx, and the confirmation/creation step is IOURequestStepConfirmation.tsx, both under src/pages/iou/request/step. When a participant is chosen, these steps call into the money request actions in IOU.ts (setMoneyRequestParticipants, and the create call for distance), which in turn resolves the target chat through ReportUtils optimistic report helpers (getOptimisticChatReport / the "get or create" logic).

The expected result in the issue explicitly references the "There is a previously existing chat between these users." error, which means the create request is resolving to a report that the client believes should be new but the optimistic report lookup returns an existing/optimistic key. When that mismatch happens for a freshly-created user option, the participant state and the derived report never stabilize, so the selector re-derives options and the confirmation navigation re-runs on every render. That render/effect loop is what locks the JS thread and freezes the app on device, rather than surfacing the error and navigating to the new chat.

Because this is a state-derivation loop tied to a newly created (non-existing) user option, it appears only when the entered email has no existing chat, which matches the exact repro in the issue.

The code snippets returned by the automated search (for example YesNoStep.tsx and App.tsx) are unrelated to the Track distance money-request flow, so the fix belongs in the IOU request step files and their supporting actions, not those files.

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

1. In IOURequestStepParticipants.tsx (src/pages/iou/request/step/IOURequestStepParticipants.tsx), memoize the participant list and guard the "add participant" handler so selecting a newly created user option sets participants exactly once and does not re-run when the derived option identity changes on each render. Ensure any useEffect that reacts to participants has a stable dependency and an early return when the participant is already applied.

2. In IOURequestStepConfirmation.tsx (src/pages/iou/request/step/IOURequestStepConfirmation.tsx), guard the create/navigation effect with a ref (for example an isCreatingRef) so the distance-expense create is dispatched once. This prevents the confirmation step from repeatedly re-triggering creation while the optimistic report for the brand new user is still resolving.

3. In IOU.ts (src/libs/actions/IOU.ts), where the target report is resolved for a new participant, ensure the optimistic chat report is created deterministically for a user with no existing chat so ReportUtils returns a single stable report ID instead of oscillating between an existing lookup and a new optimistic report. This removes the "previously existing chat" mismatch that drives the loop and lets navigation proceed to the new chat.

Because the freeze is caused by an unstable participant/report derivation looping across renders, stabilizing the participant selection, gating the create call, and returning a deterministic optimistic report together break the loop and allow the expense to be created in the new chat as expected.

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.

[melvin-bot]

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