[Due for payment 2026-05-15] [$250] [LHN] "Fix" action badge incorrectly appears on both workspace chat and individual expense report

[MelvinBot]

Bug: "Fix" action badge appears on both workspace chat and individual expense report in LHN

When there are violations on forwarded receipts (triggering the DEW flow), the Fix action badge/pill appears on both the workspace chat and the individual expense report in the LHN. It should only appear on the workspace chat, not the individual report.

Expected behavior

The Fix action badge should only show on the workspace chat in the LHN, not on the individual expense report.

Actual behavior

Both the workspace chat and the individual expense report display the Fix icon/pill in the LHN.

Additionally:

• The expense report appears to be pinned in the LHN
• This seems correlated with the DEW error message: "This report can't be submitted. Please review the comments to resolve." — whenever that red text appears in the header, the double Fix pills also appear in the LHN

How to reproduce

No reliable repro steps yet. The reporter observed this after forwarding receipts that resulted in violations. Onyx state was shared in the Slack thread for debugging.

Related context

• This may be related to the DEW (Daily Expense Workflow) handling of violations
• Possibly related to Action Badge: Phantom GBR appears on workspace chat and disappears on click #86287 (phantom GBR on workspace chat)

Slack thread: https://expensify.slack.com/archives/C05LX9D6E07/p1775659495167829

Issue Owner

Current Issue Owner: @mallenexpensify

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022044910272916862953
• Upwork Job ID: 2044910272916862953
• Last Price Increase: 2026-04-23
• Automatic offers:
• linhvovan29546 | Reviewer | 111272259

[MelvinBot]

Proposal

What is the root cause of that problem?

The Fix badge is computed per-report in reportAttributes.ts: any report with a red brick road (violations or errors) gets actionBadge = FIX. Then, a separate error-propagation loop copies the ERROR + FIX badge from child IOU/expense reports up to their parent workspace chat.

The result: the individual expense report keeps its own Fix badge and the workspace chat also gets one via propagation — so both appear in the LHN.

This contradicts the stated intent in getViolatingReportIDForRBRInLHN, which has a comment: "We only show the RBR in the highest level, which is the expense chat." That function correctly filters to only workspace chats, but the expense report can still independently get its own Fix badge through the hasViolations flag passed to getReasonAndReportActionThatHasRedBrickRoad.

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

In reportAttributes.ts, when the Fix badge is being assigned to a report that has a chatReportID (i.e., it's a child expense/IOU report whose errors will be propagated to the parent), suppress the Fix action badge on the child report itself. The brickRoadStatus can still be set to ERROR (so the propagation loop still picks it up and marks the parent workspace chat), but the actionBadge should not be set to FIX on the child — only on the parent workspace chat via the propagation step.

Alternatively, the propagation loop at lines 333–361 could be updated to clear the actionBadge on child IOU reports after propagating the error to the parent, ensuring only the workspace chat displays the Fix pill.

What alternative solutions did you explore? (Optional)

One could modify getReasonAndReportActionThatHasRedBrickRoad in SidebarUtils.ts to skip returning a reason for IOU/expense reports that have a parent workspace chat. However, this would change the RBR semantics more broadly and might suppress legitimate error indicators on expense reports in other contexts (e.g., when viewed directly, not in the LHN).

Supporting evidence

• Per-report Fix badge assignment: reportAttributes.ts:291-296 — sets actionBadge = CONST.REPORT.ACTION_BADGE.FIX for any report with RBR
• Error propagation to parent: reportAttributes.ts:333-361 — copies ERROR + FIX from IOU reports to parent chat reports
• Intent comment: ReportUtils.ts:9155-9159 — "We only show the RBR in the highest level, which is the expense chat"
• Badge rendering: OptionRowLHN.tsx:164 — badge text is behind !isProduction gate

Possibly related: Expensify/App#86287 (phantom GBR on workspace chat), Expensify/App#86109 (Fix label on zero-amount expense)

---

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.

[melvin-bot]

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

[melvin-bot]

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

[yuvrajangadsingh]

Proposal

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

When expense reports have DEW violations, the Fix action badge appears on both the workspace chat and the individual expense report in the LHN. It should only appear on the workspace chat.

What is the root cause of that problem?

Two independent code paths both assign actionBadge = FIX:

Path 1 -- per-report computation (reportAttributes.ts:280-296): getReasonAndReportActionThatHasRedBrickRoad is called for every report. For expense reports with DEW violations, report action errors end up in reportErrors via getAllReportErrors (which merges report.errorFields and report action errors at ReportUtils.ts:9434-9457). That makes hasErrors = true inside getReasonAndReportActionThatHasRedBrickRoad (SidebarUtils.ts:656-663), which returns {reason: HAS_ERRORS}. This triggers:

// reportAttributes.ts:292-296
if (reasonAndReportAction) {
    brickRoadStatus = CONST.BRICK_ROAD_INDICATOR_STATUS.ERROR;
    actionBadge = CONST.REPORT.ACTION_BADGE.FIX;   // <-- set on expense report itself
    ...
}

Path 2 -- propagation loop (reportAttributes.ts:333-361): After per-report computation, the loop sees the expense report has brickRoadStatus=ERROR and report.chatReportID pointing to the workspace chat, so it also sets actionBadge=FIX on the workspace chat.

Both paths fire, so both the expense report and workspace chat display the Fix pill.

Critically, getViolatingReportIDForRBRInLHN (ReportUtils.ts:9155-9159) already enforces the correct rule with an explicit comment: "We only show the RBR in the highest level, which is the expense chat" -- but this only governs the violation-based path. The error-based path (hasErrors) in getReasonAndReportActionThatHasRedBrickRoad has no such guard, so expense reports slip through.

Affected surface: reportAttributes.ts:292-296 (the only place actionBadge is assigned per-report before the propagation loop).

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

In reportAttributes.ts, add isPolicyExpenseChat to the import from @libs/ReportUtils:

// existing
import {generateIsEmptyReport, generateReportAttributes, hasVisibleReportFieldViolations, isArchivedReport, isValidReport} from '@libs/ReportUtils';

// new
import {generateIsEmptyReport, generateReportAttributes, hasVisibleReportFieldViolations, isArchivedReport, isPolicyExpenseChat, isValidReport} from '@libs/ReportUtils';

Then change lines 292-296 in reportAttributes.ts:

if (reasonAndReportAction) {
    brickRoadStatus = CONST.BRICK_ROAD_INDICATOR_STATUS.ERROR;
    // Only set the Fix badge on workspace chats, not on child expense reports.
    // Reusing the same rule as getViolatingReportIDForRBRInLHN in ReportUtils.ts:9156:
    // "We only show the RBR in the highest level, which is the expense chat."
    // brickRoadStatus=ERROR stays so the propagation loop below still marks the parent.
    const isChildOfPolicyExpenseChat = !!chatReport && isPolicyExpenseChat(chatReport);
    if (!isChildOfPolicyExpenseChat) {
        actionBadge = CONST.REPORT.ACTION_BADGE.FIX;
        actionTargetReportActionID = reasonAndReportAction.reportAction?.reportActionID;
    }
}

chatReport is already available on line 253 in the same loop iteration, so no extra lookups are needed. The propagation loop at lines 333-361 remains unchanged -- it reads brickRoadStatus=ERROR from the expense report and sets actionBadge=FIX only on the workspace chat.

Scope check -- where this should NOT fire: personal IOU reports (DM-based, where chatReport is a 1:1 DM chat, not a policy expense chat). isPolicyExpenseChat(chatReport) returns false for those, so they keep their own Fix badge as before. The fix is scoped strictly to workspace expense reports.

Scenario trace:

1. User forwards receipt → DEW violation → report action errors written to expense report's Onyx data
2. getAllReportErrors picks them up → hasErrors = true → getReasonAndReportActionThatHasRedBrickRoad returns HAS_ERRORS
3. With fix: brickRoadStatus=ERROR set, but actionBadge not set (because isPolicyExpenseChat(chatReport) = true)
4. Propagation loop sees expense report's brickRoadStatus=ERROR, adds workspace chat to chatReportIDsWithErrors
5. Workspace chat gets actionBadge=FIX -- only one Fix badge appears in LHN

What alternative solutions did you explore? (Optional)

I considered a post-propagation cleanup pass that clears actionBadge from child reports whose parent was just marked. That works but requires an extra O(n) loop over reportAttributes entries. The per-report suppression above avoids the extra pass entirely and handles incremental updates naturally since both paths run in the same reduce cycle.

I also considered fixing it in getReasonAndReportActionThatHasRedBrickRoad in SidebarUtils.ts by adding a chatReport parameter and skipping the error check when the parent is a policy expense chat. That would be more localized but would change the semantics of a shared utility used in other contexts (shouldDisplayReportInLHN at SidebarUtils.ts:258), which is riskier.

[wildan-m]

Proposal

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

In LHN, when the current user has an expense report under a workspace (policyExpenseChat) that has transaction violations on forwarded receipts that tripped the DEW (Dynamic External Workflow) submit flow, the "Fix" action badge/pill renders twice — once on the workspace chat row (expected) and again on the individual expense report row (unexpected). The individual expense report also gets hoisted to the pinned/GBR area of LHN, making it look pinned even though the user never pinned it.

What is the root cause of that problem?

Two independent paths in the derived value + sidebar logic each produce the "Fix" badge, and neither path knows the other is already doing it.

Path A — the workspace chat (parent) gets the badge legitimately.

In src/libs/actions/OnyxDerived/configs/reportAttributes.ts, the main loop calls SidebarUtils.getReasonAndReportActionThatHasRedBrickRoad(...) for every report. For the workspace chat, that call returns HAS_TRANSACTION_THREAD_VIOLATIONS because getViolatingReportIDForRBRInLHN(chat, ...) returns a non-null reportID (the policyExpenseChat is eligible):

App/src/libs/ReportUtils.ts

Lines 9155 to 9159 in d866817

	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;
	}

Back in reportAttributes.ts, that triggers the ERROR branch, which stamps brickRoadStatus = ERROR and actionBadge = FIX on the workspace chat:

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

Lines 291 to 296 in d866817

	// if report has errors or violations, show red dot
	if (reasonAndReportAction) {
	brickRoadStatus = CONST.BRICK_ROAD_INDICATOR_STATUS.ERROR;
	actionBadge = CONST.REPORT.ACTION_BADGE.FIX;
	actionTargetReportActionID = reasonAndReportAction.reportAction?.reportActionID;
	}

Then the explicit error-propagation loop at the end of the same file adds an extra safety net — any child IOU/expense report with ERROR causes the parent chat to also be stamped with ERROR + FIX:

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

Lines 333 to 361 in d866817

	// 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.
	const attributes = reportAttributes[report.reportID];
	if (report.chatReportID && report.reportID !== report.chatReportID && 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 workspace chat is guaranteed to surface the "Fix" badge in LHN. That is the expected behavior.

Path B — the child expense report is force-shown in LHN with its own badge.

In the DEW-submit-failed scenario, getAllReportActionsErrorsAndReportActionThatRequiresAttention seeds reportActionErrors.dewSubmitFailed for the expense report (owner, status OPEN, has an active DEW_SUBMIT_FAILED action):

App/src/libs/ReportUtils.ts

Lines 9410 to 9416 in d866817

	if (!isReportArchived && isReportOwner(report) && report?.statusNum === CONST.REPORT.STATUS_NUM.OPEN) {
	const mostRecentActiveDEWAction = getMostRecentActiveDEWSubmitFailedAction(reportActionsArray);
	if (mostRecentActiveDEWAction) {
	reportActionErrors.dewSubmitFailed = getMicroSecondOnyxErrorWithTranslationKey('iou.error.genericCreateFailureMessage');
	reportAction = mostRecentActiveDEWAction;
	}
	}

That error flows into getAllReportErrors, so when generateReportAttributes runs for the expense report, hasErrors is true and getReasonAndReportActionThatHasRedBrickRoad returns HAS_ERRORS. The same main-loop branch as Path A then stamps brickRoadStatus = ERROR and actionBadge = FIX on the expense report itself.

When shouldDisplayReportInLHN runs, it computes hasErrorsOtherThanFailedReceipt (true, because dewSubmitFailed isn't the smartscan-failed message filtered at line 9502) and takes the early-return force-show branch:

App/src/libs/SidebarUtils.ts

Lines 263 to 272 in d866817

	const hasErrorsOtherThanFailedReceipt = hasReportErrorsOtherThanFailedReceipt(report, chatReport, doesReportHaveViolations, transactionViolations, transactions, reportAttributes);
	const isReportInAccessible = report?.errorFields?.notFound;
	if (isOneTransactionThread(report, parentReport, parentReportAction)) {
	return {shouldDisplay: false};
	}
	// Handle reports with errors
	if (hasErrorsOtherThanFailedReceipt && !isReportInAccessible) {
	return {shouldDisplay: true, hasErrorsOtherThanFailedReceipt: true};
	}

That early-return bypasses the normal shouldReportBeInOptionList filtering, so the individual expense report lands in reportsToDisplay with hasErrorsOtherThanFailedReceipt: true and ends up in the pinned/GBR or error bucket in categorizeReportsForLHN:

App/src/libs/SidebarUtils.ts

Lines 467 to 488 in d866817

	const isPinned = !!report.isPinned;
	const requiresAttention = !!report?.requiresAttention;
	if (isPinned || requiresAttention) {
	pinnedAndGBRReports.push(miniReport);
	continue;
	}
	const reportNameValuePairsKey = `${ONYXKEYS.COLLECTION.REPORT_NAME_VALUE_PAIRS}${reportID}`;
	const rNVPs = reportNameValuePairs?.[reportNameValuePairsKey];
	const isArchived = isArchivedNonExpenseReport(report, !!rNVPs?.private_isArchived);
	const hasErrors = !!report.hasErrorsOtherThanFailedReceipt && !isArchived;
	if (hasErrors) {
	errorReports.push(miniReport);
	} else if (reportsDrafts?.[reportID]) {
	draftReports.push(miniReport);
	} else if (isArchived) {
	archivedReports.push(miniReport);
	} else {
	nonArchivedReports.push(miniReport);
	}

Result: the parent workspace chat (Path A) and the child expense report (Path B) both appear as separate LHN rows, each with their own "Fix" action badge, and the child looks "pinned" because it sorts with the pinned/GBR group.

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

Break Path B's force-show at its source: in shouldDisplayReportInLHN, stop taking the hasErrorsOtherThanFailedReceipt early-return for an expense report whose parent chat is a workspace chat that will already surface the error via Path A. The parent propagation in reportAttributes.ts guarantees the workspace chat gets ERROR + FIX whenever the child expense report does, so there is no scenario where removing the child's force-show causes the error to be hidden from the user.

Concretely, in src/libs/SidebarUtils.ts, adjust the block at line 270 so the force-show branch only runs when the current report is NOT an expense report under a policyExpenseChat. When the report is an expense report with a policyExpenseChat parent, skip the force-show and let the rest of shouldDisplayReportInLHN (hidden override check + shouldReportBeInOptionList) make the final decision — which, for a passive expense report that the user isn't viewing, pinning, or drafting into, will resolve to shouldDisplay: false. That eliminates the duplicate LHN row and the "appears pinned" side effect.

Import isExpenseReport and isPolicyExpenseChat from ReportUtils in the SidebarUtils module (both are already available and re-exported there).

No changes are needed in reportAttributes.ts: the main-loop ERROR stamping and the propagation loop must continue to run so the workspace chat row keeps showing the "Fix" badge. We are only changing how the LHN display layer filters, not how attributes are computed — which leaves other consumers of brickRoadStatus/actionBadge on the child report (e.g. MoneyReportHeader, OptionsListUtils) unaffected.

An existing Jest test in tests/unit/SidebarUtilsTest.ts covers shouldDisplayReportInLHN and should be extended with a case that constructs: a policyExpenseChat parent + a child EXPENSE report that has hasErrorsOtherThanFailedReceipt === true (simulated by putting a dewSubmitFailed-style error in the report's derived attributes). The expectation is that shouldDisplayReportInLHN returns shouldDisplay: false for the child while the parent chat still returns shouldDisplay: true.

Compare branch: https://github.com/Expensify/App/compare/main...wildan-m:App:wildan/88160-lhn-dedupe-fix-badge-on-expense-report?expand=1

What alternative solutions did you explore? (Optional)

• Clear brickRoadStatus/actionBadge on the child inside the propagation loop in reportAttributes.ts. Rejected because those fields are consumed by non-LHN surfaces (notably MoneyReportHeader at src/components/MoneyReportHeader.tsx where it drives the header status icon and tooltip). Nulling them on the child would correctly deduplicate LHN but would regress the expense-report header experience — the DEW submit error would stop surfacing when the user actually opens the expense report, which is the screen where they need to see it.

• Filter in hasReportErrorsOtherThanFailedReceipt (ReportUtils.ts) instead of in shouldDisplayReportInLHN. Rejected because that helper is also called from reasonForReportToBeInOptionList for non-LHN option lists (search, share-to pickers) where the caller actually does want to know whether the report has non-receipt errors. Changing it there would leak LHN-specific policy into a generic utility.

• Prevent the child from getting ERROR in the main loop by short-circuiting getReasonAndReportActionThatHasRedBrickRoad for child expense reports whose parent is a policyExpenseChat. Same objection as the first alternative — it would regress MoneyReportHeader and any other screen that legitimately reads the expense report's own brickRoadStatus. The LHN is the only surface where the duplication is a problem, so the fix belongs at the LHN boundary.

[github-actions]

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