[Due for payment 2025-08-29] [$250] Expense - Category is missing can not be set when cancel payment on moved expense

[nlemma]

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.88-0
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught during regression testing, add the test name, ID and link from TestRail: https://test-management.browserstack.com/projects/2148171/test-runs/TR-331/folder/12015305/39317673/816209935
Email or phone of affected tester (no customers): gocemate+b2154012@gmail.com
Issue reported by: Applause Internal Team
Device used: Lenovo 80ES / Windows 10 Pro
App Component: Money Requests

Action Performed:

1. Login with new gmail account
2. Create workspace
3. Open new chat> Pay > Complete the flow
4. Go to expense details> More> Change workspace
5. Go to workspace chat> Expense details> More> Cancel payment
6. Navigate to other chat and switch back to workspace chat
7. Verify Category missing violation is displayed
8. Click on expense to open expense detail page

Expected Result:

Use should be able to set category

Actual Result:

User can not see the category section

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug6904978_1754037476954.Recording__5912.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~021952994691565798350
• Upwork Job ID: 1952994691565798350
• Last Price Increase: 2025-08-06
• Automatic offers:
• FitseTLT | Contributor | 108400243

Issue Owner

Current Issue Owner: @dylanexpensify

[melvin-bot]

Triggered auto assignment to @dylanexpensify (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.

Expense - Category is missing can not be set when cancel payment on moved expense

What is the root cause of that problem?

We are filtering out pay type IOU actions here

App/src/libs/ReportActionsUtils.ts

Lines 1303 to 1308 in 1dfb9cb

	if (
	!isIOUActionMatchingTransactionList(action, reportTransactionIDs, true) ||
	(getOriginalMessage(action)?.type === CONST.IOU.REPORT_ACTION_TYPE.PAY && !isTestTransactionReport(report))
	) {
	continue;
	}

the origin of this confusion is that there are two types of pay type ious. ONe is isSentMoneyReportAction which are iou actions linked to an expense created when you send money and the other is pay actions that are system messages created to a pay action in an iou report.

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

The reason we filter out pay type ious is to avoid paid elswehere like pay system messages but we haven't properly identified them in our logic.
We should only filter out pay type IOU actions if they don't have IOU details in their original message taking the logic from the way we determine isTransactionThread here

App/src/libs/ReportActionsUtils.ts

Line 421 in 1dfb9cb

(originalMessage?.type === CONST.IOU.REPORT_ACTION_TYPE.PAY && !!originalMessage?.IOUDetails)

if (
            !isIOUActionMatchingTransactionList(action, reportTransactionIDs, true) ||
            (getOriginalMessage(action)?.type === CONST.IOU.REPORT_ACTION_TYPE.PAY && !getOriginalMessage(action)?.IOUDetails && !isTestTransactionReport(report))
        ) {
            continue;
        }

Alternatively we can utilize isTransactionThread itself instead to filter out with a better coverage. I also assume we can remove isTestTransactionReport condition as I suspect the condition was added to avoid similar issue as this one on a test paid transaction report because mc test transaction is also as a paid expense.

In addtion to this we also have a similar problem were we are totally avoiding pay type iou actions from editable money requests here

App/src/libs/ReportUtils.ts

Lines 4057 to 4061 in 1dfb9cb

	const allowedReportActionType: Array<ValueOf<typeof CONST.IOU.REPORT_ACTION_TYPE>> = [CONST.IOU.REPORT_ACTION_TYPE.TRACK, CONST.IOU.REPORT_ACTION_TYPE.CREATE];
	const originalMessage = getOriginalMessage(reportAction);
	const actionType = originalMessage?.type;
	if (!actionType || !allowedReportActionType.includes(actionType)) {

We need to replace it with isTransactionThread

if (!isTransactionThread(reportAction)) {
        return false;
    }

BTW there are other places in the code base where we are wrongly using CONST.IOU.REPORT_ACTION_TYPE.PAY type iou actions without considering send money flow type pay type ious like here

App/src/libs/ReportActionsUtils.ts

Lines 1233 to 1234 in 1dfb9cb

	const isIOUActionTypeExcludedFromFiltering = (type: OriginalMessageIOU['type'] | undefined) =>
	[CONST.IOU.REPORT_ACTION_TYPE.SPLIT, CONST.IOU.REPORT_ACTION_TYPE.TRACK, CONST.IOU.REPORT_ACTION_TYPE.PAY].some((actionType) => actionType === type);

which totally avoids pay type ious as has no linked report
Similarly here we assume all pay type ious in the calculation of one transaction thread report action without considering non-isSentMoneyReportAction pure pay actions

App/src/libs/ReportActionsUtils.ts

Line 1314 in 1dfb9cb

iouRequestTypesSet.has(actionType) &&

So we can update this and other logics in the code base related to pay actions in the pr.

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

We can test getOneTransactionThreadReportAction and canEditMoneyRequest that they properly handle one transaction thread report of a pay type iou with iou details in their original message

What alternative solutions did you explore? (Optional)

[melvin-bot]

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

[melvin-bot]

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

[hungvu193]

Will review this weekend