[$250] IOU - No RBR on the expense after user go online

[izarutskaya]

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.78-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: EDGE https://github.com/Expensify/Expensify/issues/415531
Email or phone of affected tester (no customers): undefined
Issue reported by: Applause Internal Team

Action Performed:

1. Open the NewDot app
2. Go offline
3. Submit an expense to a new user
4. From another device, send a message to the user from step 2
5. Back to the main device, go online. The chat report of the new user will have a RBR.

Expected Result:

5. Back to the main device, go online. The chat report of the new user will have a RBR.

Actual Result:

No RBR with the expense after the user goes online

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7134608_1776740812424.415531.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022057067475703528267
• Upwork Job ID: 2057067475703528267
• Last Price Increase: 2026-09-02

Issue Owner

Current Issue Owner: @hoangzinh

[MelvinBot]

Proposal

What is the root cause of that problem?

The issue is a race condition during reconnection between the SequentialQueue replay and Pusher/ReconnectApp updates.

When the user goes back online, three things happen concurrently:

1. SequentialQueue flushes — the offline-queued REQUEST_MONEY command fires. Its server response onyxData and successData/failureData are queued (deferred via queueOnyxUpdates) and only applied after ALL queue items complete.

2. Pusher reconnects — missed events from step 4 (message sent to User B from another device) are delivered. ONYX_API_UPDATE events call Onyx.update() directly, waiting only for the current in-flight request (not the whole queue). MULTIPLE_EVENTS go through applyOnyxUpdatesReliably, which can trigger GetMissingOnyxMessages — a side-effect request whose response applies immediately.

3. ReconnectApp fires, also queued as a WRITE in the SequentialQueue.

The step-4 message creates (or updates) a 1:1 chat between User A and User B on the server. When Pusher delivers this server-side chat report during reconnection, it MERGEs into Onyx immediately — overwriting the optimistic chat report's pendingFields and IOU references that were set offline. The server data does not include client-side optimistic pendingFields (the server doesn't track them), so the pending/error state is effectively wiped. When the deferred REQUEST_MONEY failureData finally applies (setting errorFields.createChat at MoneyRequestBuilder.ts:878-883), the report state it targets may have already been replaced, preventing the RBR from appearing.

Additionally, the incremental update path in reportAttributes.ts returns early when only ONYXKEYS.NETWORK changes (offline→online), meaning the isOffline flag used in receipt error checking is not immediately re-evaluated on reconnection.

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

The fix should ensure that Pusher updates arriving during reconnection do not overwrite optimistic pending state for queued WRITE requests that haven't been processed yet. Two approaches:

1. Protect optimistic data during queue flush: When the SequentialQueue is actively flushing, Pusher-delivered Onyx MERGEs for reports that have pendingFields set locally should be deferred (or deep-merged to preserve pendingFields), rather than blindly overwriting the optimistic state. This could be implemented in the ONYX_API_UPDATE handler or in applyOnyxUpdatesReliably by checking if the target report key has pending queue items before allowing immediate application.

2. Alternatively, re-apply optimistic data after Pusher merge: After any Pusher/ReconnectApp update that modifies a report with a pending SequentialQueue request, re-apply the optimistic data from the persisted request to ensure the pending indicators survive. This is conceptually similar to how queueOnyxUpdates already defers WRITE response data.

The first approach is cleaner — it prevents the problem at the source rather than trying to recover from it.

What alternative solutions did you explore? (Optional)

Considered whether the willShowGreenSubmit suppression in reportAttributes.ts could be suppressing the RBR. When requiresAttention && actionBadge === SUBMIT, the RBR is intentionally hidden AND error propagation to the parent chat is skipped (needsParentChatErrorPropagation stays false). However, this is unlikely to trigger for a brand-new expense to a new user since requiresAttention requires specific conditions like submitted status or fraud alerts.

Investigation details

Key code paths:

• Optimistic IOU data creation with pendingFields: MoneyRequestBuilder.ts:449-476
• Failure data setting errors on chat/IOU reports: MoneyRequestBuilder.ts:868-925
• WRITE response queuing (deferred application): OnyxUpdates.ts:35
• RBR determination: SidebarUtils.ts:693-736
• Error propagation from IOU to chat reports: reportAttributes.ts:376-411
• Reconnection flow: Reconnect.ts:57-84
• Pusher ONYX_API_UPDATE bypassing queue: User.ts:963-985
• Incremental update early return on NETWORK-only change: reportAttributes.ts:254-256

Possibly related open issues:

• Expensify/App#87754 — No error shown to user A after requested amount changes by user B and A reconnects (similar offline/reconnect race pattern)
• Expensify/App#88680 — RBR not shown offline after SmartScan amount edit (related RBR display issue)

---

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.

[Abdulloh0109]

Proposal

What is the root cause of that problem?

I traced this bug by starting from the UI surface that should display the RBR. The red dot on a chat row in LHN is rendered by OptionRow.tsx#L272-L287, gated by option.brickRoadIndicator === CONST.BRICK_ROAD_INDICATOR_STATUS.ERROR. That value comes from the derived reportAttributes.brickRoadStatus (set by SidebarUtils.getOptionData when it builds the LHN row).

The brickRoadStatus for the parent CHAT report is set by the propagation loop in reportAttributes.ts#L376-L411. This loop only marks a chat with ERROR when it finds a child IOU report whose report.chatReportID points back to that chat AND whose own attributes have needsParentChatErrorPropagation === true.

needsParentChatErrorPropagation is set in reportAttributes.ts#L322-L323 only when SidebarUtils.getReasonAndReportActionThatHasRedBrickRoad returns a reason. That function reads reportErrors, which is computed by ReportUtils.getAllReportErrors from report.errorFields and reportAction errors.

In this repro the chain breaks at the link between the IOU report and its parent chat. When user A submits an expense to a brand-new user B while offline, MoneyRequestBuilder.ts#L1204-L1208 calls buildOptimisticChatReport, generating a fresh OPTIMISTIC chatReportID (call it X). The optimistic IOU report Y is created with chatReportID = X. The failureData in MoneyRequestBuilder.ts#L879-L893 writes errorFields.createChat onto both X and Y.

Meanwhile the SECOND device sends a message to the same new user B, so by the time A comes online the server already holds a real 1:1 chat Z between A and B. The sync brings Z into A's Onyx. The queued offline request fires; the server reconciles the participants and the response operates against Z rather than X. After successData, the optimistic chat X ends up orphaned (no longer the chat A sees in LHN — that row is Z), while the IOU report Y still carries chatReportID = X. Nothing in the merge path rewrites Y.chatReportID from X to Z.

So when the propagation loop runs, for IOU report Y it asks reportAttributes[X] and either finds nothing (line reportAttributes.ts#L400 continue) or marks the orphaned X instead of the visible row Z. The chat row the user actually sees in LHN is Z, and Z has no errorFields of its own and no IOU child pointing back to it — so it gets no RBR. The expense's error state never reaches the user.

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

The fix belongs in the reconciliation layer, not in the renderer. There are two concrete places to address it, both needed because each guards a different surface.

1. Rewrite the IOU's chatReportID when a server-side chat already exists for the same participants. Mirror the existing duplicate-chat detection in MoneyRequestBuilder.ts#L1198 (getChatByParticipants): on the device that comes online, before queued IOU requests fire, detect that the optimistic chat X has a matching server chat Z for the same participants, then MERGE-update the IOU report Y so chatReportID = Z (and the transaction thread report's parent IDs accordingly). This restores the IOU→chat link the propagation loop relies on. The merge should preserve errorFields and pendingFields so error and pending status flow through to Z. The cleanest place is RequestConflictUtils.resolveOpenReportDuplicationConflictAction, which already handles OPEN_REPORT collisions on the same participants — extend it to relink dependent IOU/transactionThread reports.

2. Make sure failureData lands on the chat the user sees. When the request fails after coming online, MoneyRequestBuilder.ts#L877-L884 currently writes errorFields.createChat keyed on the optimistic chat ID built at request time. After step (1) the optimistic ID is no longer the user's chat row, so the failureData keys must be updated alongside the relink so the error attaches to Z, not X. The IOU reportAction error in MoneyRequestBuilder.ts#L908-L922 similarly needs to land on Z's reportActions when reconciliation happened.

No render-layer change is needed — once Y.chatReportID matches the visible LHN row, the existing propagation in reportAttributes.ts#L376-L411 and the existing getAllReportErrors aggregation will flow the error up to the chat row that the user sees and the RBR will appear.

What alternative solutions did you explore? (Optional)

1. Add transaction.errors as a third source inside getAllReportErrors. Reading transaction.errors (which IS set in failureData at MoneyRequestBuilder.ts#L898-L902) feels tempting because the transaction is the most "atomic" record of the failure. But the transaction's reportID field references the IOU report Y, which still points at orphaned X — so even widening the error sources cannot make the propagation hit Z. It addresses a symptom (errors visible at all) but not the root mismatch.

2. Walk participants in the propagation loop to find the right chat. I considered making the loop in reportAttributes.ts fall back to "find any chat whose participantsList equals the IOU's participants" when reportAttributes[chatReportID] is missing. This works but adds an O(reports × participants) scan into a hot derived computation and shifts business logic (chat identity) into the LHN view layer. The conflict-resolution layer already understands participant-based chat identity (via getChatByParticipants and resolveOpenReportDuplicationConflictAction), so the fix is cheaper and more correct there.

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.

[dilshodmackbook-sketch]

🚨 Edited by proposal-police: This proposal was edited at 2026-05-20 11:56:30 UTC.

Proposal

What is the root cause of that problem?

When you submit an expense to a brand-new user while offline, the app optimistically creates the 1:1 DM chat report, the IOU/expense report and the transaction — all linked together through the optimistic chat reportID (the expense report's chatReportID/parentReportID).

If a DM with that same user is created in the meantime from another device, the server already has a report for that set of participants. When the queued request finally syncs, the server responds with a preexistingReportID on the optimistic chat report, and replaceOptimisticReportWithActualReport swaps it out — it deletes the optimistic chat report (Onyx.set(REPORT_<id>, null)) and copies the chat report's own fields onto the preexisting one.

The problem is that it only migrates the chat report itself. The dependent IOU/expense report still has chatReportID/parentReportID pointing at the now-deleted optimistic chat reportID.

RBR for an expense is propagated from the IOU report up to iouReport.chatReportID in the reportAttributes derived value — reportAttributes.ts#L352-L383:

chatReportIDsWithErrors.add(report.chatReportID);
...
for (const chatReportID of chatReportIDsWithErrors) {
    if (!reportAttributes[chatReportID]) {
        continue; // <-- stale optimistic ID -> entry is undefined -> RBR dropped
    }

Because report.chatReportID is the stale (deleted) optimistic ID, reportAttributes[chatReportID] is undefined, the loop hits continue, and the ERROR status is never applied to the visible preexisting chat report. So no RBR shows on the new user's chat.

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

In replaceOptimisticReportWithActualReport, when swapping a DM/group-DM optimistic chat report for the preexisting one, also re-point any reports that still reference the old optimistic chat reportID:

        if (!parentReportActionID) {
            // DMs and group-DMs don't have parent actions, so we only need to merge report data and preserve existing participants
            Onyx.set(`${ONYXKEYS.COLLECTION.REPORT}${preexistingReportID}`, {
                ...report,
                reportID: preexistingReportID,
                preexistingReportID: null,
                // Replacing the existing report's participants to avoid duplicates
                participants: existingReport?.participants ?? report.participants,
            });
+
+           // Re-point IOU/expense reports created under the optimistic chat report so chat-scoped
+           // logic (RBR propagation, navigation, report previews) resolves to the preexisting report.
+           for (const dependentReport of Object.values(allReports ?? {})) {
+               if (!dependentReport || dependentReport.reportID === reportID) {
+                   continue;
+               }
+               if (dependentReport.chatReportID === reportID || dependentReport.parentReportID === reportID) {
+                   Onyx.merge(`${ONYXKEYS.COLLECTION.REPORT}${dependentReport.reportID}`, {
+                       ...(dependentReport.chatReportID === reportID && {chatReportID: preexistingReportID}),
+                       ...(dependentReport.parentReportID === reportID && {parentReportID: preexistingReportID}),
+                   });
+               }
+           }
        } else {

With the IOU/expense report now correctly linked to the preexisting chat report, the propagation loop in reportAttributes.ts finds a valid reportAttributes[chatReportID] entry and applies the ERROR status, so the expense's red dot surfaces on the new user's chat report.

What alternative solutions did you explore? (Optional)

1. Harden the RBR propagation in reportAttributes.ts to resolve the chat report through the preexistingReportID mapping (or fall back when the entry is missing). Rejected — this only patches the RBR symptom; the stale chatReportID also breaks navigation, "view expense" deep links and report-preview lookups, so the underlying data still needs to be made consistent.

2. Extend the HandleUnusedOptimisticID middleware to rewrite already-applied optimistic Onyx data (not just persisted request params) via deepReplaceKeysAndValues. Rejected — that middleware operates on request payloads and shouldn't reach into the live Onyx store; replaceOptimisticReportWithActualReport already owns optimistic-report cleanup and has allReports in scope, so the fix belongs there.

[yusufdeveloper2903]

Proposal

What is the root cause of that problem?

The repro forces the preexisting-report dedup path. Submitting the expense offline to a brand‑new user optimistically creates a DM chat (R_opt) plus a child IOU report whose chatReportID and parentReportID are set to that optimistic chat ID:

App/src/libs/ReportUtils.ts

Lines 6561 to 6583 in e8c6aa8

	return {
	type: CONST.REPORT.TYPE.IOU,
	chatReportID,
	currency,
	managerID: payerAccountID,
	ownerAccountID: payeeAccountID,
	participants,
	reportID: optimisticIOUReportID ?? generateReportID(),
	stateNum: isSendingMoney ? CONST.REPORT.STATE_NUM.APPROVED : CONST.REPORT.STATE_NUM.SUBMITTED,
	statusNum: isSendingMoney ? CONST.REPORT.STATUS_NUM.REIMBURSED : CONST.REPORT.STATE_NUM.SUBMITTED,
	total,
	unheldTotal: total,
	nonReimbursableTotal: 0,
	unheldNonReimbursableTotal: 0,
	// We don't translate reportName because the server response is always in English
	reportName: `${payerEmail} owes ${formattedTotal}`,
	parentReportID: chatReportID,
	created,
	lastVisibleActionCreated: created,
	fieldList: policy?.fieldList,
	parentReportActionID,
	};

Meanwhile the message sent from the other device makes the server create the real DM (R_real). When the main device goes online, the API responds with preexistingReportID = R_real on the optimistic chat, and replaceOptimisticReportWithActualReport runs. In the DM branch it copies the chat into R_real and deletes R_opt, but it never touches the child IOU report — that report is left with chatReportID/parentReportID still pointing at the now‑deleted R_opt:

App/src/libs/actions/replaceOptimisticReportWithActualReport.ts

Lines 98 to 106 in e8c6aa8

	if (!parentReportActionID) {
	// DMs and group-DMs don't have parent actions, so we only need to merge report data and preserve existing participants
	Onyx.set(`${ONYXKEYS.COLLECTION.REPORT}${preexistingReportID}`, {
	...report,
	reportID: preexistingReportID,
	preexistingReportID: null,
	// Replacing the existing report's participants to avoid duplicates
	participants: existingReport?.participants ?? report.participants,
	});

The RBR on a chat row is produced by propagating each IOU report's error up to its chatReportID. The propagation loop adds report.chatReportID to the error set and then bails if that chat has no attributes entry:

App/src/libs/actions/OnyxDerived/configs/reportAttributes.ts

Lines 388 to 411 in e8c6aa8

	const attributes = reportAttributes[report.reportID];
	if (
	report.chatReportID &&
	report.reportID !== report.chatReportID &&
	(attributes?.needsParentChatErrorPropagation || attributes?.brickRoadStatus === CONST.BRICK_ROAD_INDICATOR_STATUS.ERROR)
	) {
	chatReportIDsWithErrors.add(report.chatReportID);
	}
	}
	// Apply the error status to the parent chat reports.
	for (const chatReportID of chatReportIDsWithErrors) {
	if (!reportAttributes[chatReportID]) {
	continue;
	}
	// Clone the entry before mutating — it may be a reference carried over from
	// currentValue.reports that wasn't recomputed in this incremental run.
	reportAttributes[chatReportID] = {
	...reportAttributes[chatReportID],
	brickRoadStatus: CONST.BRICK_ROAD_INDICATOR_STATUS.ERROR,
	actionBadge: CONST.REPORT.ACTION_BADGE.FIX,
	};
	}

Since the IOU report's chatReportID is the deleted R_opt, reportAttributes[R_opt] is undefined, the loop hits continue, and the error is never applied to R_real → the new user's chat shows no RBR. (Without the step‑4 message there is no preexisting report, the optimistic chat simply becomes real, the IOU report's chatReportID stays valid, and the RBR shows correctly — which is why this only reproduces with the second device.)

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

When the optimistic DM is replaced, re-point its child reports (the offline‑created IOU/expense report) at the preexisting chat so the report graph stays consistent and the RBR can propagate. In the DM branch of replaceOptimisticReportWithActualReport:

             if (!parentReportActionID) {
                 // DMs and group-DMs don't have parent actions, so we only need to merge report data and preserve existing participants
                 Onyx.set(`${ONYXKEYS.COLLECTION.REPORT}${preexistingReportID}`, {
                     ...report,
                     reportID: preexistingReportID,
                     preexistingReportID: null,
                     // Replacing the existing report's participants to avoid duplicates
                     participants: existingReport?.participants ?? report.participants,
                 });
+
+                // An expense submitted in this chat while offline created a child IOU report that still
+                // references the now-deleted optimistic chat. Re-point it (and any other child report) at
+                // the preexisting chat, otherwise reportAttributes can't propagate its RBR up to the chat row.
+                for (const childReport of Object.values(allReports ?? {})) {
+                    if (!childReport || (childReport.chatReportID !== reportID && childReport.parentReportID !== reportID)) {
+                        continue;
+                    }
+                    Onyx.merge(`${ONYXKEYS.COLLECTION.REPORT}${childReport.reportID}`, {
+                        ...(childReport.chatReportID === reportID ? {chatReportID: preexistingReportID} : {}),
+                        ...(childReport.parentReportID === reportID ? {parentReportID: preexistingReportID} : {}),
+                    });
+                }
             } else {

reportID, preexistingReportID, and the module‑level allReports cache are already in scope. After the merge, the IOU report's chatReportID resolves to R_real, the propagation loop applies BRICK_ROAD_INDICATOR_STATUS.ERROR to R_real, and the new user's chat shows the RBR. This mirrors how the thread/IOU branches already re-point childReportID for the transaction‑thread case.

What alternative solutions did you explore? (Optional)

• Patch the propagation loop to fall back to parentReportID or resolve the chat via the report‑preview action when chatReportID is missing — rejected. An IOU report whose chatReportID points at a deleted report is itself corrupt; navigation, report‑preview lookups, and any code that walks chatReportID would still break. Fixing the data at the dedup source is the single‑source‑of‑truth fix.
• Migrate REPORT_ACTIONS from R_opt to R_real during the DM dedup — unnecessary for the RBR (propagation keys off the report graph via chatReportID, not the action) and risks duplicating actions the server already returns under the preexisting report.

[KJ21-ENG]

Proposal

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

After a user submits an expense to a new user while offline, then another device creates/sends a message in that same 1:1 chat before the first device reconnects, the visible chat row can come online without the expected RBR for the expense.

What is the root cause of that problem?

The offline money request starts with an optimistic 1:1 chat when no local chat exists for the participants:

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

Lines 1198 to 1209 in ad1f336

	if (!chatReport) {
	chatReport = getChatByParticipants([payerAccountID, payeeAccountID]) ?? null;
	}
	// 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,
	});

The optimistic IOU report is then created with both chatReportID and parentReportID pointing at that optimistic chat:

App/src/libs/ReportUtils.ts

Lines 6556 to 6578 in ad1f336

	return {
	type: CONST.REPORT.TYPE.IOU,
	chatReportID,
	currency,
	managerID: payerAccountID,
	ownerAccountID: payeeAccountID,
	participants,
	reportID: optimisticIOUReportID ?? generateReportID(),
	stateNum: isSendingMoney ? CONST.REPORT.STATE_NUM.APPROVED : CONST.REPORT.STATE_NUM.SUBMITTED,
	statusNum: isSendingMoney ? CONST.REPORT.STATUS_NUM.REIMBURSED : CONST.REPORT.STATE_NUM.SUBMITTED,
	total,
	unheldTotal: total,
	nonReimbursableTotal: 0,
	unheldNonReimbursableTotal: 0,
	// We don't translate reportName because the server response is always in English
	reportName: `${payerEmail} owes ${formattedTotal}`,
	parentReportID: chatReportID,
	created,
	lastVisibleActionCreated: created,
	fieldList: policy?.fieldList,
	parentReportActionID,
	};

In this repro, the second device creates the real server chat while the first device is offline. When the first device reconnects, the optimistic chat can be replaced with the server's preexistingReportID. The DM/group-DM branch in replaceOptimisticReportWithActualReport copies the optimistic chat data into the preexisting report and clears the optimistic report, but it does not update dependent IOU reports that still reference the optimistic chat ID:

App/src/libs/actions/replaceOptimisticReportWithActualReport.ts

Lines 98 to 106 in ad1f336

	if (!parentReportActionID) {
	// DMs and group-DMs don't have parent actions, so we only need to merge report data and preserve existing participants
	Onyx.set(`${ONYXKEYS.COLLECTION.REPORT}${preexistingReportID}`, {
	...report,
	reportID: preexistingReportID,
	preexistingReportID: null,
	// Replacing the existing report's participants to avoid duplicates
	participants: existingReport?.participants ?? report.participants,
	});

The LHN RBR is propagated from an IOU report to report.chatReportID in reportAttributes. If that chatReportID is the deleted optimistic report, reportAttributes[chatReportID] is missing and the loop skips it:

App/src/libs/actions/OnyxDerived/configs/reportAttributes.ts

Lines 376 to 411 in ad1f336

	// Propagate errors from IOU reports to their parent chat reports.
	const chatReportIDsWithErrors = new Set<string>();
	for (const report of Object.values(reports)) {
	if (!report?.reportID) {
	continue;
	}
	// If this is an IOU report and its calculated attributes have an error,
	// then we need to mark its parent chat report.
	// We read `needsParentChatErrorPropagation` rather than `brickRoadStatus` because the per-report
	// pass suppresses the child's own brickRoadStatus when the parent workspace chat is accessible —
	// we still need to propagate the error up so the parent shows the indicator.
	const attributes = reportAttributes[report.reportID];
	if (
	report.chatReportID &&
	report.reportID !== report.chatReportID &&
	(attributes?.needsParentChatErrorPropagation || attributes?.brickRoadStatus === CONST.BRICK_ROAD_INDICATOR_STATUS.ERROR)
	) {
	chatReportIDsWithErrors.add(report.chatReportID);
	}
	}
	// Apply the error status to the parent chat reports.
	for (const chatReportID of chatReportIDsWithErrors) {
	if (!reportAttributes[chatReportID]) {
	continue;
	}
	// Clone the entry before mutating — it may be a reference carried over from
	// currentValue.reports that wasn't recomputed in this incremental run.
	reportAttributes[chatReportID] = {
	...reportAttributes[chatReportID],
	brickRoadStatus: CONST.BRICK_ROAD_INDICATOR_STATUS.ERROR,
	actionBadge: CONST.REPORT.ACTION_BADGE.FIX,
	};
	}

So the RBR is applied to neither the deleted optimistic chat nor the visible preexisting chat.

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

Fix the data reconciliation in replaceOptimisticReportWithActualReport. When the no-parentReportActionID DM/group-DM branch replaces an optimistic chat with preexistingReportID, also relink any dependent reports that still point at the old optimistic chat.

Concretely, after setting REPORT${preexistingReportID}, iterate allReports and merge updates for reports where:

• childReport.chatReportID === reportID
• childReport.parentReportID === reportID

Those fields should be replaced with preexistingReportID. This can be done with individual Onyx.merge calls or a small Onyx.mergeCollection batch, preserving all other IOU report fields such as errors, pending fields, totals, and participants.

Once the IOU report points at the visible preexisting chat, the existing reportAttributes propagation will find a valid parent chat attributes entry and set brickRoadStatus: ERROR on the chat row, so no renderer change is needed.

What alternative solutions did you explore? (Optional)

One alternative is to make reportAttributes recover from a missing chatReportID by searching for another chat with matching participants or a report preview action. I would avoid that because it puts reconciliation logic in a hot derived-value path and only fixes the RBR symptom. The underlying report graph would still be stale for navigation, previews, and any other code that reads chatReportID.

Another option is to recompute all report attributes when a chat is replaced. That still would not make the visible chat the IOU report's parent; the correct fix is to update the stale references at the point where the optimistic report is replaced.

[mukhrr]

Proposal

What is the root cause of that problem?

When a money request is created offline against a brand-new user, NewDot generates an optimistic chat report (with a temporary optimisticChatReportID), an optimistic IOU report whose chatReportID points at that temporary ID, and any optimistic transaction violations. While the device is still offline, the user's second device sends a chat message to the same new user — this creates a real chat report on the backend that does not exist on the offline device yet.

When device 1 comes back online, two things race:

1. Pusher pushes down the real chat report (and the message report action) created by device 2.
2. The queued RequestMoney API call is replayed and the server response merges into Onyx.

The IOU report on device 1 still has chatReportID = <optimisticChatReportID> (the placeholder). It is never re-pointed to the real chat the server returned. The error/violation propagation in reportAttributes.ts walks report.chatReportID to mark the parent chat as having an RBR — but that lookup misses, because the real chat report has a different reportID than the optimistic one the IOU still references:

App/src/libs/actions/OnyxDerived/configs/reportAttributes.ts

Lines 376 to 411 in e3b5200

	// Propagate errors from IOU reports to their parent chat reports.
	const chatReportIDsWithErrors = new Set<string>();
	for (const report of Object.values(reports)) {
	if (!report?.reportID) {
	continue;
	}
	// If this is an IOU report and its calculated attributes have an error,
	// then we need to mark its parent chat report.
	// We read `needsParentChatErrorPropagation` rather than `brickRoadStatus` because the per-report
	// pass suppresses the child's own brickRoadStatus when the parent workspace chat is accessible —
	// we still need to propagate the error up so the parent shows the indicator.
	const attributes = reportAttributes[report.reportID];
	if (
	report.chatReportID &&
	report.reportID !== report.chatReportID &&
	(attributes?.needsParentChatErrorPropagation || attributes?.brickRoadStatus === CONST.BRICK_ROAD_INDICATOR_STATUS.ERROR)
	) {
	chatReportIDsWithErrors.add(report.chatReportID);
	}
	}
	// Apply the error status to the parent chat reports.
	for (const chatReportID of chatReportIDsWithErrors) {
	if (!reportAttributes[chatReportID]) {
	continue;
	}
	// Clone the entry before mutating — it may be a reference carried over from
	// currentValue.reports that wasn't recomputed in this incremental run.
	reportAttributes[chatReportID] = {
	...reportAttributes[chatReportID],
	brickRoadStatus: CONST.BRICK_ROAD_INDICATOR_STATUS.ERROR,
	actionBadge: CONST.REPORT.ACTION_BADGE.FIX,
	};
	}

Compounding this, getViolatingReportIDForRBRInLHN early-bails on anything that isn't a policy expense chat, so for a 1:1 IOU the only way RBR can surface on the chat row is via the IOU-report-to-chat propagation above — which is exactly the path the stale chatReportID breaks:

App/src/libs/ReportUtils.ts

Lines 9079 to 9091 in e3b5200

	function getViolatingReportIDForRBRInLHN(report: OnyxEntry<Report>, transactionViolations: OnyxCollection<TransactionViolation[]>): string | null {
	// We only show the RBR in the highest level, which is the expense chat
	if (!report || !isPolicyExpenseChat(report)) {
	return null;
	}
	// We only show the RBR to the submitter
	if (!isCurrentUserSubmitter(report)) {
	return null;
	}
	if (!report.policyID || !deprecatedReportsByPolicyID) {
	return null;
	}

End result: the IOU still has its violations/errors locally, but the chat report shown in LHN never gets brickRoadStatus = ERROR, so no RBR appears.

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

I think we should make the propagation in reportAttributes.ts resilient to a stale chatReportID by resolving the IOU report's parent chat through the chat that actually carries it as parentReportActionID, falling back to report.chatReportID only when the optimistic ID still matches a known report. The core change:

-        if (
-            report.chatReportID &&
-            report.reportID !== report.chatReportID &&
-            (attributes?.needsParentChatErrorPropagation || attributes?.brickRoadStatus === CONST.BRICK_ROAD_INDICATOR_STATUS.ERROR)
-        ) {
-            chatReportIDsWithErrors.add(report.chatReportID);
-        }
+        const resolvedChatReportID =
+            report.chatReportID && reports?.[`${ONYXKEYS.COLLECTION.REPORT}${report.chatReportID}`]
+                ? report.chatReportID
+                : ReportUtils.getParentChatReportIDForIOU(report, reports);
+        if (
+            resolvedChatReportID &&
+            report.reportID !== resolvedChatReportID &&
+            (attributes?.needsParentChatErrorPropagation || attributes?.brickRoadStatus === CONST.BRICK_ROAD_INDICATOR_STATUS.ERROR)
+        ) {
+            chatReportIDsWithErrors.add(resolvedChatReportID);
+        }

Where getParentChatReportIDForIOU is a small helper in ReportUtils.ts that finds the chat report whose reportActions contain a REPORTPREVIEW action pointing at report.reportID (this is the same relationship getOneTransactionThreadReportID already relies on). When the optimistic chat is replaced by the real one coming from device 2, the real chat is the one carrying the REPORTPREVIEW action, so the lookup recovers automatically.

The second part of the fix is to also re-point the IOU's chatReportID once the real chat is known, so other consumers (not just the LHN derived value) see a consistent graph. The cleanest place is the success path of RequestMoney in getMoneyRequestInformation / its onyxData.successData: when the server returns a chatReport whose reportID differs from the optimistic one we sent, also merge {chatReportID: <real>} onto the IOU report and {reportID: <real>} onto the linked transaction. That covers the offline → online reconcile for any future code paths that read iouReport.chatReportID directly.

No translation changes are needed; this is purely a state-reconciliation fix.

What alternative solutions did you explore?

• Relax getViolatingReportIDForRBRInLHN to also accept 1:1 IOU chats. That would fix the surface symptom but it changes RBR semantics for every 1:1 expense globally (not just this offline edge case) and risks false positives, since the function's policy/admin gating was added on purpose to restrict RBR to the submitter on the workspace chat.
• Drop the optimistic chat report entirely when an incoming server chat for the same participant arrives. Cleaner conceptually, but it touches the generic chat-creation pipeline and risks regressions in unrelated DM/IOU flows; the targeted reconcile above is much smaller in blast radius.
• Force a full recompute of reportAttributes whenever a chat report is replaced. Works, but it's a perf hit on every chat reconcile and still leaves iouReport.chatReportID stale for other consumers.

[melvin-bot]

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

[melvin-bot]

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