Approve: spurious LHN green dot after approving (stale hasOutstandingChildRequest on expense report, not cleared optimistically)

[MelvinBot]

Problem

After approving an expense report, the green Approve action badge in the LHN disappears (correct) but is immediately replaced by a green dot ("greenlight" / GBR indicator). The green dot should not be there — the report is fully actioned. Navigating away and back (which triggers OpenReport) clears the green dot, confirming the optimistic state is wrong and the server state is right.

Reproduction

1. Be the approver of an expense report that shows the green Approve badge in the LHN.
2. Approve the report.
3. Observe the LHN row: the Approve badge is replaced by a spurious green dot.
4. Navigate to another report and back (triggers OpenReport).
5. The green dot disappears.

Expected: After approving, the LHN row shows no action badge and no green dot.
Actual: A green dot lingers until OpenReport refetches server data.

Root cause

The LHN green dot for an expense report is driven by the report's own hasOutstandingChildRequest field. In getReasonAndReportActionThatRequiresAttention:

const hasValidIOUAction =
    ((optionOrReport.hasOutstandingChildRequest === true && !hasStaleChildRequest) || iouReportActionToApproveOrPay?.reportActionID) &&
    (policy?.reimbursementChoice !== CONST.POLICY.REIMBURSEMENT_CHOICES.REIMBURSEMENT_NO || !hasOnlyPendingTransactions);

When hasOutstandingChildRequest === true, this returns HAS_CHILD_REPORT_AWAITING_ACTION, which sets brickRoadStatus = INFO (the green dot) in reportAttributes.ts.

The optimistic approve flow in approveMoneyRequest (ReportWorkflow.ts:480-526) correctly updates stateNum, statusNum, managerID, and nextStep on the expense report, and recomputes hasOutstandingChildRequest — but only on the parent chat report:

const updatedExpenseReport = {
    ...expenseReport,
    // ... stateNum, statusNum, managerID, nextStep ...   <-- no hasOutstandingChildRequest
};
optimisticData.push({ ...key: REPORT${expenseReport.reportID}, value: updatedExpenseReport });

if (chatReport) {
    optimisticData.push({
        key: `${ONYXKEYS.COLLECTION.REPORT}${expenseReport.chatReportID}`,   // <-- chat report, not expense report
        value: { hasOutstandingChildRequest: hasOutstandingChildRequest(chatReport, updatedExpenseReport, ...) },
    });
}

So the expense report keeps its stale hasOutstandingChildRequest: true until OpenReport returns fresh server data with false.

Evidence (Onyx for the expense report)

reportID: 8367965920096919, type: expense, stateNum: 2, statusNum: 3, non-reimbursable (total: -8710, nonReimbursableTotal: -8710, reimbursableTotal: 0).

Immediately after optimistic approve (buggy — green dot shows):

"hasOutstandingChildRequest": true,
"nextStep": { "icon": "hourglass", "messageKey": "waitingToApprove" }

After navigating away/back — OpenReport (correct — no green dot):

"hasOutstandingChildRequest": false,
"nextStep": { "icon": "checkmark", "messageKey": "noFurtherAction" }

The single field that toggles the green dot here is hasOutstandingChildRequest. (nextStep does not factor into the green-dot or action-badge computation, though note the optimistic nextStep above also lands as stale waitingToApprove rather than the server's noFurtherAction — the nextStep optimistic value is built by buildOptimisticNextStep and should resolve to noFurtherAction for this reimbursableSpend === 0 case; worth confirming during the fix.)

Recommended fix

In approveMoneyRequest, include a recomputed hasOutstandingChildRequest on the expense report's optimistic merge (updatedExpenseReport), not just on the chat report — so the green dot clears optimistically instead of waiting for OpenReport. Add a matching failureData entry to roll it back if the approve fails.

Investigation details

• Green dot (brickRoadIndicator === INFO) is read by SidebarUtils.getOptionData from the derived reportAttributes.brickRoadStatus (reportAttributes.ts:299-342), which delegates to getReasonAndReportActionThatRequiresAttention in ReportUtils.ts.
• The green Approve action badge is computed separately by getBadgeFromIOUReport / canApproveIOU (ReportWorkflow.ts); after approval canApproveIOU returns false, so the badge correctly disappears.
• nextStep is not consumed by either indicator.

---

Reported in Slack.

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022065561772412405023
• Upwork Job ID: 2065561772412405023
• Last Price Increase: 2026-06-12
• Automatic offers:
• aimane-chnaif | Contributor | 111711542

Issue Owner

Current Issue Owner: @aimane-chnaif

[MelvinBot]

Proposal

✅ High confidence — I independently verified every claim below against the code at f295b9d (the same SHA the issue references).

What is the root cause of that problem?

The LHN green dot for an expense report is driven by the expense report's own hasOutstandingChildRequest field. The optimistic approve flow recomputes that field on the parent chat report only — it never updates it on the expense report — so the expense report keeps the stale value true until OpenReport returns fresh server data.

Mechanism, end to end:

1. The green dot is brickRoadIndicator === INFO, produced when getReasonAndReportActionThatRequiresAttention returns HAS_CHILD_REPORT_AWAITING_ACTION. That branch fires when hasValidIOUAction is truthy, and hasValidIOUAction keys off optionOrReport.hasOutstandingChildRequest === true (ReportUtils.ts:4253-4255).
2. In approveMoneyRequest, the optimistic updatedExpenseReport merge sets stateNum, statusNum, managerID, nextStep, and pendingFields — but not hasOutstandingChildRequest (ReportWorkflow.ts:480-507).
3. The recomputed hasOutstandingChildRequest is only written to the chat report key (...REPORT}${expenseReport.chatReportID}), not the expense report key (ReportWorkflow.ts:509-526).

So the expense report's LHN row reads its own stale hasOutstandingChildRequest: true, shows the green dot, and only clears when OpenReport refetches false — exactly matching the reproduction (navigate away + back fixes it).

The Approve badge disappears correctly because it is computed separately via canApproveIOU, which returns false after approval — confirming the green dot is the only stale indicator.

Verification notes

• updatedExpenseReport field list confirmed at ReportWorkflow.ts:480-502 — no hasOutstandingChildRequest.
• hasOutstandingChildRequest recompute scoped to chatReportID confirmed at ReportWorkflow.ts:509-526.
• Green-dot branch (HAS_CHILD_REPORT_AWAITING_ACTION) gated on hasOutstandingChildRequest === true confirmed at ReportUtils.ts:4290-4296.
• failureData already restores the chat report's hasOutstandingChildRequest (ReportWorkflow.ts:593-599) and the expense report's stateNum/statusNum/nextStep (ReportWorkflow.ts:607-621) — but not the expense report's hasOutstandingChildRequest (since the optimistic data never touched it).

Alternative explanation considered & ruled out: hasValidIOUAction is also truthy if iouReportActionToApproveOrPay?.reportActionID exists. But after approval canApproveIOU returns false (the badge correctly disappears), so that action is gone — leaving stale hasOutstandingChildRequest as the sole cause. ✓

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

In approveMoneyRequest, include a recomputed hasOutstandingChildRequest on the expense report's optimistic merge (updatedExpenseReport), computed the same way it is for the chat report (via hasOutstandingChildRequest(...)). This clears the green dot optimistically instead of waiting for OpenReport.

Add a matching failureData entry for the expense report key (alongside ReportWorkflow.ts:607-621) that restores hasOutstandingChildRequest: expenseReport.hasOutstandingChildRequest so the green dot reappears if the approve request fails.

What alternative solutions did you explore? (Optional)

None needed — the fix mirrors the existing chat-report handling onto the expense report. (Side note: the issue also flags that the optimistic nextStep lands as waitingToApprove rather than the server's noFurtherAction for the reimbursableSpend === 0 case. nextStep does not drive the green dot or the badge, so it's out of scope for this bug, but worth a separate look.)

Possibly related

• GBR/action button desync: Approve button missing in Inbox despite GBR, workspace chat flips to Fix with loading skeleton #93166 — GBR/action-button desync after approve (same family of optimistic GBR-state bugs; may share a fix).

---

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

[KJ21-ENG]

Proposal

What is the root cause of that problem?

The LHN row reads reportAttributes.brickRoadStatus as its brick-road indicator. reportAttributes sets that status to INFO whenever the report is marked as requiring attention, and getReasonAndReportActionThatRequiresAttention() treats the report's own hasOutstandingChildRequest === true as a valid IOU attention signal.

App/src/libs/SidebarUtils.ts

Lines 919 to 921 in fec6b33

	result.brickRoadIndicator = reportAttributes?.brickRoadStatus;
	result.actionBadge = reportAttributes?.actionBadge;
	result.actionTargetReportActionID = reportAttributes?.actionTargetReportActionID;

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

Lines 357 to 360 in fec6b33

	// if report does not have error, check if it should show green dot
	if (brickRoadStatus !== CONST.BRICK_ROAD_INDICATOR_STATUS.ERROR && requiresAttention) {
	brickRoadStatus = CONST.BRICK_ROAD_INDICATOR_STATUS.INFO;
	actionBadge = actionGreenBadge;

App/src/libs/ReportUtils.ts

Lines 4436 to 4440 in fec6b33

	// Has a child report that is awaiting action (e.g. approve, pay, add bank account) from current user
	const hasStaleChildRequest = isTripRoom(optionOrReport) && (optionOrReport.transactionCount ?? 0) === 0;
	const hasValidIOUAction =
	((optionOrReport.hasOutstandingChildRequest === true && !hasStaleChildRequest) || iouReportActionToApproveOrPay?.reportActionID) &&
	(policy?.reimbursementChoice !== CONST.POLICY.REIMBURSEMENT_CHOICES.REIMBURSEMENT_NO || !hasOnlyPendingTransactions);

App/src/libs/ReportUtils.ts

Lines 4475 to 4480 in fec6b33

	if (hasValidIOUAction) {
	return {
	reason: CONST.REQUIRES_ATTENTION_REASONS.HAS_CHILD_REPORT_AWAITING_ACTION,
	reportAction: iouReportActionToApproveOrPay,
	actionBadge,
	};

In approveMoneyRequest(), the optimistic expense-report merge spreads the old expenseReport and updates stateNum, statusNum, managerID, nextStep, and pendingFields, but it never overwrites hasOutstandingChildRequest. The only optimistic recomputation of hasOutstandingChildRequest is written to the parent chat report key.

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

Lines 534 to 560 in fec6b33

	const updatedExpenseReport = {
	...expenseReport,
	...(shouldAddOptimisticApproveAction
	? {
	lastMessageText: getReportActionText(optimisticApprovedReportAction),
	lastMessageHtml: getReportActionHtml(optimisticApprovedReportAction),
	}
	: {}),
	// For DEW policies, don't optimistically update stateNum, statusNum, managerID, or nextStep
	// because DEW determines the actual workflow on the backend
	...(isDEWPolicy
	? {}
	: {
	stateNum: predictedNextState,
	statusNum: predictedNextStatus,
	managerID,
	nextStep: optimisticNextStep ?? undefined,
	pendingFields: {
	partial: full ? null : CONST.RED_BRICK_ROAD_PENDING_ACTION.UPDATE,
	nextStep: CONST.RED_BRICK_ROAD_PENDING_ACTION.UPDATE,
	},
	}),
	};
	optimisticData.push({
	onyxMethod: Onyx.METHOD.MERGE,
	key: `${ONYXKEYS.COLLECTION.REPORT}${expenseReport.reportID}`,
	value: updatedExpenseReport,

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

Lines 563 to 578 in fec6b33

	if (chatReport) {
	optimisticData.push({
	onyxMethod: Onyx.METHOD.MERGE,
	key: `${ONYXKEYS.COLLECTION.REPORT}${expenseReport.chatReportID}`,
	value: {
	hasOutstandingChildRequest: hasOutstandingChildRequest(
	chatReport,
	updatedExpenseReport,
	currentUserEmailParam,
	currentUserAccountIDParam,
	// TODO: https://github.com/Expensify/App/issues/66512
	// eslint-disable-next-line @typescript-eslint/no-deprecated
	getAllTransactionViolations(),
	undefined,
	),
	},

So after the approval, the green Approve badge can disappear while the expense report itself still carries the stale hasOutstandingChildRequest: true. Derived attributes then keep marking that expense report as requiring attention, which shows the plain green dot until OpenReport replaces the expense report with the server's false value.

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

Update approveMoneyRequest() so the non-DEW optimistic expense-report merge explicitly clears the expense report's own outstanding-child flag for the current approver, e.g. set hasOutstandingChildRequest: false on updatedExpenseReport in the same branch that predicts stateNum, statusNum, managerID, and nextStep. Keep the existing parent chat report recomputation unchanged, because the parent chat field represents whether any child report still needs attention from the current user.

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

Lines 534 to 578 in fec6b33

	const updatedExpenseReport = {
	...expenseReport,
	...(shouldAddOptimisticApproveAction
	? {
	lastMessageText: getReportActionText(optimisticApprovedReportAction),
	lastMessageHtml: getReportActionHtml(optimisticApprovedReportAction),
	}
	: {}),
	// For DEW policies, don't optimistically update stateNum, statusNum, managerID, or nextStep
	// because DEW determines the actual workflow on the backend
	...(isDEWPolicy
	? {}
	: {
	stateNum: predictedNextState,
	statusNum: predictedNextStatus,
	managerID,
	nextStep: optimisticNextStep ?? undefined,
	pendingFields: {
	partial: full ? null : CONST.RED_BRICK_ROAD_PENDING_ACTION.UPDATE,
	nextStep: CONST.RED_BRICK_ROAD_PENDING_ACTION.UPDATE,
	},
	}),
	};
	optimisticData.push({
	onyxMethod: Onyx.METHOD.MERGE,
	key: `${ONYXKEYS.COLLECTION.REPORT}${expenseReport.reportID}`,
	value: updatedExpenseReport,
	});
	if (chatReport) {
	optimisticData.push({
	onyxMethod: Onyx.METHOD.MERGE,
	key: `${ONYXKEYS.COLLECTION.REPORT}${expenseReport.chatReportID}`,
	value: {
	hasOutstandingChildRequest: hasOutstandingChildRequest(
	chatReport,
	updatedExpenseReport,
	currentUserEmailParam,
	currentUserAccountIDParam,
	// TODO: https://github.com/Expensify/App/issues/66512
	// eslint-disable-next-line @typescript-eslint/no-deprecated
	getAllTransactionViolations(),
	undefined,
	),
	},

Add the matching expense-report rollback in failureData, restoring hasOutstandingChildRequest: expenseReport.hasOutstandingChildRequest alongside the existing rollback of stateNum, statusNum, nextStep, and pending fields. Without an explicit rollback, an approve failure would leave the optimistic false in place under the same Onyx merge behavior.

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

Lines 637 to 674 in fec6b33

	const failureData: Array<
	OnyxUpdate<
	| typeof ONYXKEYS.COLLECTION.REPORT
	| typeof ONYXKEYS.COLLECTION.REPORT_ACTIONS
	| typeof ONYXKEYS.COLLECTION.NEXT_STEP
	| typeof ONYXKEYS.COLLECTION.REPORT_METADATA
	| typeof ONYXKEYS.COLLECTION.TRANSACTION
	| typeof ONYXKEYS.COLLECTION.TRANSACTION_VIOLATIONS
	>
	> = [
	{
	onyxMethod: Onyx.METHOD.MERGE,
	key: `${ONYXKEYS.COLLECTION.REPORT}${expenseReport.chatReportID}`,
	value: {
	hasOutstandingChildRequest: chatReport?.hasOutstandingChildRequest,
	},
	},
	{
	onyxMethod: Onyx.METHOD.MERGE,
	key: `${ONYXKEYS.COLLECTION.NEXT_STEP}${expenseReport.reportID}`,
	value: expenseReportCurrentNextStepDeprecated ?? null,
	},
	];
	if (!isDEWPolicy) {
	failureData.push({
	onyxMethod: Onyx.METHOD.MERGE,
	key: `${ONYXKEYS.COLLECTION.REPORT}${expenseReport.reportID}`,
	value: {
	statusNum: expenseReport.statusNum,
	stateNum: expenseReport.stateNum,
	nextStep: expenseReport.nextStep ?? null,
	pendingFields: {
	partial: null,
	nextStep: null,
	},
	},
	});

Leave ReportUtils.getReasonAndReportActionThatRequiresAttention(), reportAttributes, and SidebarUtils alone. Those shared consumers are correctly reflecting the report state they receive; the bug is that the approve action leaves stale optimistic state on the expense report. Also leave the DEW branch alone unless we are also ready to predict its workflow state, because that branch intentionally avoids optimistic state/status/next-step changes.

Test coverage:

• Add/update a tests/actions/IOUTest/ReportWorkflowTest.ts approve case where an expense report starts with hasOutstandingChildRequest: true, has a parent chat report, and has no next approver. After approveMoneyRequest(), assert the optimistic expense-report update sets hasOutstandingChildRequest to false.
• In the same test or a companion test, assert the approve failureData restores expenseReport.hasOutstandingChildRequest.
• Cover that the parent chat report's hasOutstandingChildRequest recomputation still runs independently.
• For the reported non-reimbursable case, assert the optimistic next step remains NO_FURTHER_ACTION when the predicted status is APPROVED and reimbursableSpend === 0, matching the existing next-step branch.

App/src/libs/NextStepUtils.ts

Lines 827 to 830 in fec6b33

	case CONST.REPORT.STATUS_NUM.APPROVED: {
	if (isInvoiceReport(report) || !isPayer(currentUserAccountIDParam, currentUserEmailParam, report, undefined) || reimbursableSpend === 0) {
	optimisticNextStep = noActionRequired;

What alternative solutions did you explore? (Optional)

Changing the LHN/report-attribute condition to ignore hasOutstandingChildRequest for approved reports would hide stale source data in a shared attention path instead of fixing the optimistic state that differs from the server.

Using getOutstandingChildRequest(updatedExpenseReport) is also insufficient here because that helper returns an empty object for non-open expense reports, which would not clear a stale true under an Onyx merge. The approve path needs to write an explicit false for the expense report field it is making non-actionable.

[melvin-bot]

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

[lorretheboy]

Proposal

What is the root cause of that problem?

The LHN green dot for an expense report is driven by that report's own hasOutstandingChildRequest field — when it is true, getReasonAndReportActionThatRequiresAttention returns HAS_CHILD_REPORT_AWAITING_ACTION, which becomes brickRoadStatus = INFO:

App/src/libs/ReportUtils.ts

Lines 4253 to 4255 in f295b9d

	const hasValidIOUAction =
	((optionOrReport.hasOutstandingChildRequest === true && !hasStaleChildRequest) || iouReportActionToApproveOrPay?.reportActionID) &&
	(policy?.reimbursementChoice !== CONST.POLICY.REIMBURSEMENT_CHOICES.REIMBURSEMENT_NO || !hasOnlyPendingTransactions);

When the current user approves, the optimistic update in approveMoneyRequest rebuilds updatedExpenseReport with the new stateNum/statusNum/managerID/nextStep, but never touches hasOutstandingChildRequest, so the stale true is carried straight through the merge:

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

Lines 480 to 507 in f295b9d

	const updatedExpenseReport = {
	...expenseReport,
	...(shouldAddOptimisticApproveAction
	? {
	lastMessageText: getReportActionText(optimisticApprovedReportAction),
	lastMessageHtml: getReportActionHtml(optimisticApprovedReportAction),
	}
	: {}),
	// For DEW policies, don't optimistically update stateNum, statusNum, managerID, or nextStep
	// because DEW determines the actual workflow on the backend
	...(isDEWPolicy
	? {}
	: {
	stateNum: predictedNextState,
	statusNum: predictedNextStatus,
	managerID,
	nextStep: optimisticNextStep ?? undefined,
	pendingFields: {
	partial: full ? null : CONST.RED_BRICK_ROAD_PENDING_ACTION.UPDATE,
	nextStep: CONST.RED_BRICK_ROAD_PENDING_ACTION.UPDATE,
	},
	}),
	};
	optimisticData.push({
	onyxMethod: Onyx.METHOD.MERGE,
	key: `${ONYXKEYS.COLLECTION.REPORT}${expenseReport.reportID}`,
	value: updatedExpenseReport,
	});

The recomputed hasOutstandingChildRequest is only written to the parent chat report, not the expense report:

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

Lines 509 to 526 in f295b9d

	if (chatReport) {
	optimisticData.push({
	onyxMethod: Onyx.METHOD.MERGE,
	key: `${ONYXKEYS.COLLECTION.REPORT}${expenseReport.chatReportID}`,
	value: {
	hasOutstandingChildRequest: hasOutstandingChildRequest(
	chatReport,
	updatedExpenseReport,
	currentUserEmailParam,
	currentUserAccountIDParam,
	// TODO: https://github.com/Expensify/App/issues/66512
	// eslint-disable-next-line @typescript-eslint/no-deprecated
	getAllTransactionViolations(),
	undefined,
	),
	},
	});
	}

Chain: approve → expense report keeps hasOutstandingChildRequest: true → hasValidIOUAction stays true → green dot shows. Meanwhile the Approve badge clears (driven separately by canApproveIOU), so all that lingers is the dot until OpenReport returns the server's false.

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

In the same non-DEW branch that already updates stateNum/statusNum/managerID, also set hasOutstandingChildRequest: false on updatedExpenseReport. The current user has just approved this report, so nothing on it awaits their action — this mirrors the server's OpenReport value (false) and clears the dot optimistically.

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

Lines 488 to 501 in f295b9d

	// For DEW policies, don't optimistically update stateNum, statusNum, managerID, or nextStep
	// because DEW determines the actual workflow on the backend
	...(isDEWPolicy
	? {}
	: {
	stateNum: predictedNextState,
	statusNum: predictedNextStatus,
	managerID,
	nextStep: optimisticNextStep ?? undefined,
	pendingFields: {
	partial: full ? null : CONST.RED_BRICK_ROAD_PENDING_ACTION.UPDATE,
	nextStep: CONST.RED_BRICK_ROAD_PENDING_ACTION.UPDATE,
	},
	}),

Add the matching rollback to failureData (restore expenseReport.hasOutstandingChildRequest), alongside the existing expense-report rollback entry, so the dot comes back if the approve fails:

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

Lines 607 to 621 in f295b9d

	if (!isDEWPolicy) {
	failureData.push({
	onyxMethod: Onyx.METHOD.MERGE,
	key: `${ONYXKEYS.COLLECTION.REPORT}${expenseReport.reportID}`,
	value: {
	statusNum: expenseReport.statusNum,
	stateNum: expenseReport.stateNum,
	nextStep: expenseReport.nextStep ?? null,
	pendingFields: {
	partial: null,
	nextStep: null,
	},
	},
	});
	}

The nextStep landing as stale waitingToApprove is a separate, non-blocking issue (it doesn't feed the dot or badge), so I'd keep this fix scoped to hasOutstandingChildRequest and confirm buildOptimisticNextStep resolves to noFurtherAction for the reimbursableSpend === 0 case separately.

What alternative solutions did you explore? (Optional)

Recompute the value instead of hard-setting false — but hasOutstandingChildRequest iterates a chat report's child IOU actions, so it isn't the right tool for the expense report's own field, and after a self-approve the answer is unconditionally false for the current user. Setting it directly is simpler and correct for both the full-approval and forward-to-next-approver paths.

[melvin-bot]

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

[godzillaxbox19982014-lgtm]

Proposal

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

Approve: spurious LHN green dot after approving (stale hasOutstandingChildRequest on expense report, not cleared optimistically)

What is the root cause of that problem?

I traced this to the path that handles expense report, hasOutstandingChildRequest, GBR:

• src/pages/iou/request/step/confirmation/useExpenseSubmission.ts:867 (splitBillAndOpenReport): splitBillAndOpenReport({
• src/pages/iou/request/step/confirmation/useExpenseSubmission.ts:1021 (dismissModalAndOpenReportInInboxTabHelper): dismissModalAndOpenReportInInboxTabHelper(chatReportID, undefined, reportTransactions.length > 0);
• src/libs/ReportPrimaryActionUtils.ts:153 (ReportPrimaryActionUtils): return isExpenseReport && isReportSubmitter && isOpenReport && reportTransactions.length !== 0;
• The local evidence matches this recurring failure shape: optimistic transaction/report data is written to one Onyx key but the visible list reads another derived key. Here, src/pages/iou/request/step/confirmation/useExpenseSubmission.ts:867 and src/pages/iou/request/step/confirmation/useExpenseSubmission.ts:1021 do not agree on the same expense report, hasOutstandingChildRequest, GBR value, so the user-visible path can show a missing or stale state even though nearby data already has the needed context.

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

• Update src/pages/iou/request/step/confirmation/useExpenseSubmission.ts:867 to derive expense report, hasOutstandingChildRequest, GBR from the report/transaction source that owns this flow before the value is consumed.
• Carry the same normalized value through src/pages/iou/request/step/confirmation/useExpenseSubmission.ts:1021; that follows the safer family move to align optimistic/success/failure data with the selector consumed by the screen, so the write/optimistic/read paths agree instead of only changing the visible component.
• Keep the change inside the Reports, Expenses, IOU, Transactions surface and avoid changing payment actions, personal/deleted policies.

What specific scenarios should we cover in automated tests to prevent reintroducing this issue in the future?

1. Add or update a regression in tests/unit/ReportUtils*.ts for the exact issue flow: Approve: spurious LHN green dot after approving (stale hasOutstandingChildRequest on expense report, not cleared optimistically).
2. Cover the counter-case near src/pages/iou/request/step/confirmation/useExpenseSubmission.ts:867 so valid existing expense report, hasOutstandingChildRequest, GBR behavior still works.
3. Manually repeat the issue steps after the patch and confirm the visible state/action is no longer stale.

What alternative solutions did you explore? (Optional)

• I would not add a broad new condition outside these referenced paths; the safer fix is to keep expense report, hasOutstandingChildRequest, GBR consistent at the first read/write boundary shown above.

[github-actions]

⚠️ @lorretheboy 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.

[aswin-s]

🚫 Duplicated proposal withdrawn by 🤖 ProposalPolice.

[wildan-m]

🚫 Duplicated proposal withdrawn by 🤖 ProposalPolice.