[Due for payment 2025-09-19] [$250] mWeb/Chrome - LHN - No GBR shown in ws chat after deleting report

[lanitochka17]

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.1.97-2
Reproducible in staging?: Y
Reproducible in production?: Y
If this was caught during regression testing, add the test name, ID and link from TestRail: N/A
Email or phone of affected tester (no customers): Sintayewkindu7@gmail.com
Issue reported by: Applause - Internal Team

Action Performed:

1. Navigating to staging.new.expensify.com
2. Create Workspace
3. Submit expense
4. Note there is GBR in LHN
5. Create a report in the workspace
6. Note there is GBR still
7. Delete the report created in step 5
8. Navigate to LHN

Expected Result:

GBR still exist as the expense exist in WS chat

Actual Result:

GBR is not shown after deleting Report until navigating to the WS chat

Workaround:

Unknown

Platforms:

Select the officially supported platforms where the issue was reproduced:

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

Platforms Tested:

On which of our officially supported platforms was this issue tested:

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

Screenshots/Videos

Add any screenshot/video evidence

Bug6923022_1755790540071.Recording_20250821_172755.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~021959775776292267733
• Upwork Job ID: 1959775776292267733
• Last Price Increase: 2025-08-25

Issue Owner

Current Issue Owner: @jliexpensify

[melvin-bot]

Triggered auto assignment to @jliexpensify (Bug), see https://stackoverflow.com/c/expensify/questions/14418 for more details. Please add this bug to a GH project, as outlined in the SO.

[FitseTLT]

Proposal

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

mWeb/Chrome - LHN - No GBR shown in ws chat after deleting report

What is the root cause of that problem?

We are resetting hasOutstandingChildRequest of the chatReport when deleting the report

App/src/libs/actions/Report.ts

Lines 5063 to 5067 in d7214c5

	optimisticData.push({
	onyxMethod: Onyx.METHOD.MERGE,
	key: `${ONYXKEYS.COLLECTION.REPORT}${report?.parentReportID}`,
	value: {hasOutstandingChildRequest: false},
	});

without checking if action is required from the user after that iou report is deleted

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

We need to only reset it if there is no hasOutstandingChildRequest after the deletion of the iou report so we can recalculate it via hasIOUToApproveOrPay like we do here

App/src/libs/actions/IOU.ts

Line 9674 in d7214c5

hasOutstandingChildRequest: hasIOUToApproveOrPay(chatReport, updatedExpenseReport),

But hasIOUToApproveOrPay only includes the case of approve and pay action but BE considers a request as outstanding for the case of submit action too so we will update it to hasIOUToSubmitApproveOrPay to consider the submit case too (but if needed we can apply the submit case only for our case via a param but I suggest it applies to other cases we using it currently)
we will pass the deletedReportPreviewActionID

App/src/libs/actions/IOU.ts

Lines 9586 to 9600 in d7214c5

	function getIOUReportActionToApproveOrPay(chatReport: OnyxEntry<OnyxTypes.Report>, updatedIouReport: OnyxEntry<OnyxTypes.Report>): OnyxEntry<ReportAction> {
	const chatReportActions = allReportActions?.[`${ONYXKEYS.COLLECTION.REPORT_ACTIONS}${chatReport?.reportID}`] ?? {};
	return Object.values(chatReportActions).find((action) => {
	if (!action) {
	return false;
	}
	const iouReport = updatedIouReport?.reportID === action.childReportID ? updatedIouReport : getReportOrDraftReport(action.childReportID);
	// This will be fixed as part of https://github.com/Expensify/Expensify/issues/507850
	// eslint-disable-next-line deprecation/deprecation
	const policy = getPolicy(iouReport?.policyID);
	const shouldShowSettlementButton = canIOUBePaid(iouReport, chatReport, policy) || canApproveIOU(iouReport, policy);
	return action.actionName === CONST.REPORT.ACTIONS.TYPE.REPORT_PREVIEW && shouldShowSettlementButton && !isDeletedAction(action);
	});
	}

 function getIOUReportActionToSubmitApproveOrPay(
    chatReport: OnyxEntry<OnyxTypes.Report>,
    updatedIouReport: OnyxEntry<OnyxTypes.Report>,
    deletedReportPreviewActionID?: string,
): OnyxEntry<ReportAction> {
    const chatReportActions = allReportActions?.[`${ONYXKEYS.COLLECTION.REPORT_ACTIONS}${chatReport?.reportID}`] ?? {};

    return Object.values(chatReportActions).find((action) => {
        if (!action || action.reportActionID === deletedReportPreviewActionID) {
            return false;
        }
        const iouReport = updatedIouReport?.reportID === action.childReportID ? updatedIouReport : getReportOrDraftReport(action.childReportID);
        // This will be fixed as part of https://github.com/Expensify/Expensify/issues/507850
        // eslint-disable-next-line deprecation/deprecation
        const policy = getPolicy(iouReport?.policyID);
        const reportTransactions = getReportTransactions(iouReport?.reportID);

        const shouldShowSettlementButton =
            canIOUBePaid(iouReport, chatReport, policy) || canApproveIOU(iouReport, policy) || canSubmitReport(iouReport, policy, reportTransactions, undefined, false);
        return action.actionName === CONST.REPORT.ACTIONS.TYPE.REPORT_PREVIEW && shouldShowSettlementButton && !isDeletedAction(action);
    });
}

BTW alternatively we can utilize the already existing param updatedIouReport instead by passing the deleted iouReport with pending deletion set and use it instead of deletedReportPreviewActionID in the above.

App/src/libs/actions/Report.ts

Line 5066 in d7214c5

value: {hasOutstandingChildRequest: false},

        value: {hasOutstandingChildRequest: !!getIOUReportActionToSubmitApproveOrPay(getReportOrDraftReport(report?.parentReportID), undefined, reportActionID)},

Note: We are using hasIOUToApproveOrPay here for approve action and hasOutstandingChildRequest here for pay action to recalculate hasOutstandingChildRequest of the chatReport and there is no basic difference in the functions because hasIOUToApproveOrPay takes the updatedIOUReport and hasOutstandingChildRequest takes the iouReport that was paid to recalcaulate the new value based on the changes linked to the respective actions. So I recommend to join this two functions together and use them to recalculate in all cases needed. We can easily handle it via a param updatedIOUReportOrDelettedIOUReportID which can have Report or string type and if string is passed we know that we should not consider the passed iou report id in the calculation. I also see other cases where we are wrongly resetting hasOutstandingChildRequest instead of recalculating it, for instance, for the case of delete the only money request of an iou report here

App/src/libs/actions/IOU.ts

Lines 8244 to 8246 in d7214c5

	key: `${ONYXKEYS.COLLECTION.REPORT}${chatReport?.reportID}`,
	value: {
	hasOutstandingChildRequest: false,

Therefore, we should use a centrialized DRY single function in all cases needed to recalculate hasOutstandingChildRequest instead of resetting in all cases needed 👍

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

We can add a test for deleteAppReport that it doesn't reset hasOutstandingChildRequest of the chatReport while there is action required from the user.

What alternative solutions did you explore? (Optional)

[nkdengineer]

Proposal

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

GBR is not shown after deleting Report until navigating to the WS chat

What is the root cause of that problem?

We are setting hasOutstandingChildRequest as false here

App/src/libs/actions/Report.ts

Lines 5063 to 5073 in 91f5892

	optimisticData.push({
	onyxMethod: Onyx.METHOD.MERGE,
	key: `${ONYXKEYS.COLLECTION.REPORT}${report?.parentReportID}`,
	value: {hasOutstandingChildRequest: false},
	});
	failureData.push({
	onyxMethod: Onyx.METHOD.MERGE,
	key: `${ONYXKEYS.COLLECTION.REPORT}${report?.parentReportID}`,
	value: {hasOutstandingChildRequest: report?.hasOutstandingChildRequest},
	});

It leads to us not having requiresAttention here

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

Lines 132 to 138 in 91f5892

	const {hasAnyViolations, requiresAttention, reportErrors} = generateReportAttributes({
	report,
	chatReport,
	reportActions,
	transactionViolations,
	isReportArchived,
	});

=> We don't have the field brickRoadStatus in reportAttributes Onyx data

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

Lines 145 to 148 in 91f5892

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

=> we don't have brickRoadIndicator in getOptionData function

App/src/libs/SidebarUtils.ts

Line 692 in 91f5892

result.brickRoadIndicator = reportAttributes?.brickRoadStatus;

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

We should reset the hasOutstandingChildRequest base on the same existing logic that we have in IOU.ts here

App/src/libs/actions/IOU.ts

Lines 9091 to 9108 in 91f5892

	function hasOutstandingChildRequest(chatReport: OnyxTypes.Report, excludedIOUReport: OnyxEntry<OnyxTypes.Report>, policyId?: string) {
	// This will be fixed as part of https://github.com/Expensify/Expensify/issues/507850
	// eslint-disable-next-line deprecation/deprecation
	const policy = getPolicy(policyId);
	if (!policy?.achAccount?.bankAccountID) {
	return false;
	}
	const reportActions = getAllReportActions(chatReport.reportID);
	return !!Object.values(reportActions).find((action) => {
	const iouReportID = getIOUReportIDFromReportActionPreview(action);
	if (iouReportID === excludedIOUReport?.reportID) {
	return false;
	}
	const iouReport = getReportOrDraftReport(iouReportID);
	const transactions = getReportTransactions(iouReportID);
	return canIOUBePaid(iouReport, chatReport, policy, transactions) || canIOUBePaid(iouReport, chatReport, policy, transactions, true);
	});
	}

1. We should create a new util function like getHasOutstandingChildRequest

function getHasOutstandingChildRequest(chatReport: OnyxEntry<Report>, excludedIOUReport: OnyxEntry<Report>, policyId?: string) {
    const policy = getPolicy(policyId);
    const reportActions = getAllReportActions(chatReport.reportID);
    return !!Object.values(reportActions).find((action) => {
        const iouReportID = getIOUReportIDFromReportActionPreview(action);
        if (iouReportID === excludedIOUReport?.reportID) {
            return false;
        }
        const iouReport = getReportOrDraftReport(iouReportID);
        const transactions = getReportTransactions(iouReportID);
        return canIOUBePaid(iouReport, chatReport, policy, transactions)
                || canIOUBePaid(iouReport, chatReport, policy, transactions, true)
                || canApproveIOU(iouReport, policy, transactions)
                || canSubmitReport(iouReport, policy, transactions, undefined, false); // we can pass the allViolations here
    });
}

2. Then reset the hasOutstandingChildRequest in optimisticData

    const hasOutstandingChildRequest = getHasOutstandingChildRequest(getReportOrDraftReport(parentReportID), report, report?.policyID);

    optimisticData.push({
        onyxMethod: Onyx.METHOD.MERGE,
        key: `${ONYXKEYS.COLLECTION.REPORT}${report?.parentReportID}`,
        value: {hasOutstandingChildRequest},
    });

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

None

What alternative solutions did you explore? (Optional)

We can add test for the deleteAppReport to cover this scenario

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.

[dubielzyk-expensify]

Yeah seems like a bug given there should be a GBR for the submit action, right? @trjExpensify for confirmation

[jliexpensify]

Thanks for confirming Jon - that makes sense re: the submit action.

[melvin-bot]

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