[$250] Expense - "started settling up" message is missing message sender and avatar

[jponikarchuk]

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.72-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: #56838
Email or phone of affected tester (no customers): applausetester+khcategory19@applause.expensifail.com
Issue reported by: Applause Internal Team
Device used: Mac 15.5 / Chrome
App Component: Money Requests

Action Performed:

Precondition:

• Create a workspace and disable "Delay submissions" and "Add approvals".
• Workspace is set up with bank account.
• Admin invites member to the workspace.
• Member does not have any bank account.

1. Go to staging.new.expensify.com
2. [Member] Go to workspace chat.
3. [Member] Submit an expense with amount more than $100 to the workspace chat.
4. [Admin] Open the expense report.
5. [Admin] Click Pay with business account.

Expected Result:

"started settling up" message will contain the message sender and avatar.

Actual Result:

"started settling up" message is missing message sender and avatar.

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

1.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~021939825760948040432
• Upwork Job ID: 1939825760948040432
• Last Price Increase: 2025-07-14
• Automatic offers:
• daledah | Contributor | 108065526

Issue Owner

Current Issue Owner: @lydiabarclay

[melvin-bot]

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

[melvin-bot]

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

[melvin-bot]

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

[daledah]

Proposal

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

"started settling up" message is missing message sender and avatar.

What is the root cause of that problem?

When paying with Expensify in this scenario, we create 2 actions: "REIMBURSEMENTQUEUED" and "IOU"

Both has the same actorAccountID, and IOU Pay action is before "REIMBURSEMENTQUEUED" action, so we put the Avatar and sender next to IOU Pay action and not on "REIMBURSEMENTQUEUED" action, based on the grouping actions logic.

However, we don't render IOU Pay action in PureReportActionItem

App/src/pages/home/report/PureReportActionItem.tsx

Lines 1381 to 1385 in 94658ba

	// For the `pay` IOU action on non-pay expense flow, we don't want to render anything if `isWaitingOnBankAccount` is true
	// Otherwise, we will see two system messages informing the payee needs to add a bank account or wallet
	if (isMoneyRequestAction(action) && !!report?.isWaitingOnBankAccount && getOriginalMessage(action)?.type === CONST.IOU.REPORT_ACTION_TYPE.PAY && !isSendingMoney) {
	return null;
	}

So the sender Avatar is also not rendered, and only "REIMBURSEMENTQUEUED" action is shown.

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

The logic to not render IOU Pay action was added in #30079 to fix #30075. Looking at the PR description:

For money request flow we create two IOU actions on the iou report. One is of type create and the other of type pay. So let's see how these actions are rendered on the frontend if the payee is on silver wallet(aka we add the isWaitingOnBankAccount status to the iou report).

1. IOU create action -> We use this to render a preview.
2. ReimbursementQueued action -> To show a system message that the payee needs to enable the wallet and show the enable wallet button.
3. IOU pay action -> This doesn't fall in any if block under the ReportActionItem component as a result else block gets executed for this and we render another system message asking user to add their bank account as that is the default message if the report has isWaitingOnBankAccount property set.

So we now have two system message so I have updated the code to prevent rendering any content if the IOU action type is pay and it is not a send money flow.

We can see that they implemented this way because "IOU pay action -> This doesn't fall in any if block under the ReportActionItem component as a result else block gets executed for this and we render another system message".

But the Pay action was added as a case in #63230

App/src/pages/home/report/PureReportActionItem.tsx

Lines 1021 to 1034 in 94658ba

	} else if (isActionOfType(action, CONST.REPORT.ACTIONS.TYPE.IOU) && getOriginalMessage(action)?.type === CONST.IOU.REPORT_ACTION_TYPE.PAY) {
	const wasAutoPaid = getOriginalMessage(action)?.automaticAction ?? false;
	const paymentType = getOriginalMessage(action)?.paymentType;
	if (paymentType === CONST.IOU.PAYMENT_TYPE.ELSEWHERE) {
	children = <ReportActionItemBasicMessage message={translate('iou.paidElsewhere')} />;
	} else if (wasAutoPaid) {
	children = (
	<ReportActionItemBasicMessage>
	<RenderHTML html={`<comment><muted-text>${translate('iou.automaticallyPaidWithExpensify')}</muted-text></comment>`} />
	</ReportActionItemBasicMessage>
	);
	} else {
	children = <ReportActionItemBasicMessage message={translate('iou.paidWithExpensify')} />;
	}

So I think we can safely remove this block without recreating old bug

App/src/pages/home/report/PureReportActionItem.tsx

Lines 1381 to 1385 in 94658ba

	// For the `pay` IOU action on non-pay expense flow, we don't want to render anything if `isWaitingOnBankAccount` is true
	// Otherwise, we will see two system messages informing the payee needs to add a bank account or wallet
	if (isMoneyRequestAction(action) && !!report?.isWaitingOnBankAccount && getOriginalMessage(action)?.type === CONST.IOU.REPORT_ACTION_TYPE.PAY && !isSendingMoney) {
	return null;
	}

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

None, UI Bug

What alternative solutions did you explore? (Optional)

If we decide not to show IOU Pay action, we can change the logic to determine the adjacent action to add a special case where current action is "REIMBURSEMENTQUEUED" action and previous action is IOU pay action

Add logics after here

App/src/libs/ReportActionsUtils.ts

Lines 568 to 569 in cab0e62

	function findPreviousAction(reportActions: ReportAction[], actionIndex: number): OnyxEntry<ReportAction> {
	for (let i = actionIndex + 1; i < reportActions.length; i++) {

        const isActionReimbursementQueued = isReimbursementQueuedAction(reportActions.at(actionIndex));
        const indexAction = reportActions.at(i);
        const shouldUseIndexAction =
            !isMoneyRequestAction(indexAction) ||
            !report?.isWaitingOnBankAccount ||
            getOriginalMessage(indexAction)?.type !== CONST.IOU.REPORT_ACTION_TYPE.PAY ||
            !!getOriginalMessage(indexAction)?.IOUDetails;

We'll pass report from ReportActionsList down to isConsecutiveActionMadeByPreviousActor, then findPreviousAction

App/src/pages/home/report/ReportActionsList.tsx

Line 593 in cab0e62

isConsecutiveActionMadeByPreviousActor(sortedVisibleReportActions, index)

App/src/libs/ReportActionsUtils.ts

Line 605 in cab0e62

const previousAction = findPreviousAction(reportActions, actionIndex);

And update

App/src/libs/ReportActionsUtils.ts

Line 572 in cab0e62

if (isNetworkOffline || reportActions.at(i)?.pendingAction !== CONST.RED_BRICK_ROAD_PENDING_ACTION.DELETE) {

to

if ((isNetworkOffline || reportActions.at(i)?.pendingAction !== CONST.RED_BRICK_ROAD_PENDING_ACTION.DELETE) && (!isActionReimbursementQueued || shouldUseIndexAction)) {

Here's what it will look like:

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.

[hoangzinh]

Thank you for posting proposal, @daledah. I'm reviewing it now

[hoangzinh]

Hey @daledah , your proposals makes sense to me. But I would like to understand this part

We can see that they implemented this way because "IOU pay action -> This doesn't fall in any if block under the ReportActionItem component as a result else block gets executed for this and we render another system message".
But the Pay action was added as a case in #63230

When I reverted the changes in that PR, but I couldn't find any diff before/after

[hoangzinh]

I mean why you mentioned to that PR

[daledah]

@hoangzinh If you revert only #63230, there will be no changes because IOU pay action is still not rendered because of #30079. You can try revert both PRs to see the changes.

Sorry I just take a deeper look into the issue, and the correct RCA should be:

Before #30079, IOU pay action displays started settling up, payment is held until ${submitterDisplayName} adds a bank account, which is duplicative. Now after #63230 we display "paid with Expensify" so it makes more sense now. So I think we're good to remove the logic.