[Due for payment 2025-04-07] [$250] Reports - "To" field does not show recipient after submitting track expense to other user

[IuliiaHerets]

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.8-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: Exp
Email or phone of affected tester (no customers): applausetester+ps309@applause.expensifail.com
Issue reported by: Applause Internal Team
Device used: Mac 15.3 / Chrome
App Component: Search

Action Performed:

Precondition:

• Account has self DM.

1. Go to staging.new.expensify.com
2. Go to self DM.
3. Track a manual expense.
4. Go to Reports.
5. Click on the track expense in Step 3.
6. Click on the report header.
7. Click Submit it to someone.
8. Select a user.
9. On the confirmation page, enter a merchant.
10. Submit the expense.

Expected Result:

"To" field will update and display the recipient after submitting the expense.

Actual Result:

Merchant field is updated, but "To" field stills display the current user instead of recipient.
It only updates and displays the recipient after switching report status or refreshing the page.

Workaround:

Unknown

Platforms:

• Android: Standalone
• Android: HybridApp
• Android: mWeb Chrome
• iOS: Standalone
• iOS: HybridApp
• iOS: mWeb Safari
• MacOS: Chrome / Safari
• MacOS: Desktop

Screenshots/Videos

Bug6760579_1741064288210.20250304_125255.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~021896958133996103336
• Upwork Job ID: 1896958133996103336
• Last Price Increase: 2025-03-11
• Automatic offers:
• mkzie2 | Contributor | 106615973

Issue Owner

Current Issue Owner: @sakluger

[melvin-bot]

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

[mkzie2]

🚨 Edited by proposal-police: This proposal was edited at 2025-03-10 16:20:00 UTC.

Proposal

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

Merchant field is updated, but "To" field stills display the current user instead of recipient.
It only updates and displays the recipient after switching report status or refreshing the page.

What is the root cause of that problem?

We have the logic to retrigger the Search API to update the latest data whenever there're new transactions or report actions if the query type is expense or chat respectively.

App/src/hooks/useSearchHighlightAndScroll.ts

Lines 55 to 56 in d04b29b

	// Check if there is a change in the transactions or report actions list
	if ((!isChat && hasTransactionsIDsChange) || (isChat && hasReportActionsIDsChange)) {

App/src/hooks/useSearchHighlightAndScroll.ts

Lines 65 to 66 in d04b29b

	// Trigger the search
	SearchActions.search({queryJSON, offset});

But when you convert the track expense, new report actions will be created while no new transactions will, and as the query type is currently expense, the above logic will not trigger.

❓One another question: Why is the merchant or category updated, but not to?

We have the logic here to update the snapshot data based on original data. For example, a normal transactions_123 update would also update snapshot_abc.data.transactions_123. Note that this only update whichever keys are in the transactions_123. For example, the merchant key exists in transactions type so its value would definitely be updated in snapshot.

However, in this case, the managerID key exists in snapshot data but not in transactions type. The managerID key is only evaluated and returned by the BE's Search API. So it would NOT be updated to snapshot by updateSnapshots function. And this key is used to display the receiver (to) field.

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

We can remove the query type check isChat.

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

Update the useSearchHighlightAndScrollTest to make Search call independent of query type.

What alternative solutions did you explore? (Optional)

NA

[melvin-bot]

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

[melvin-bot]

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

[jayeshmangwani]

We can remove the query type check isChat.

@mkzie2 Thanks for the proposal! But could you please elaborate more on why we added isChat query type check and why it's not needed now, so we can remove it accordingly?

[mkzie2]

@jayeshmangwani That was added in #53482 just as an optimization given the dependency between the update type and query type (i.e. reportActions updates are coupled with chat query type while transactions ones are coupled with the rest). But now we can see that dependency might not be correct in this specific case (convert track expense). There's no drawback of removing the isChat check as fas as I've tested.