[HOLD for payment 2024-12-03] [Search v1.2] - Pay button displayed next to expense after unapproving

[IuliiaHerets]

If you haven’t already, check out our contributing guidelines for onboarding and email [email protected] to request to join our Slack channel!

---

Version Number: 9.0.60.0
Reproducible in staging?: Y
Reproducible in production?: N/A - new feature, doesn't exist in prod
If this was caught during regression testing, add the test name, ID and link from TestRail:
Issue reported by: Applause Internal Team

Action Performed:

1. Go to https://staging.new.expensify.com/ and log in with an account (WS admin) that have some unapproved expenses
2. Navigate to Search
3. Click on the Approve button
4. Open the expense
5. Click on the header and unapprove the report
6. Dismiss the RHP to return to Search

Expected Result:

The Approve button is displayed next to the expense

Actual Result:

The Pay button is displayed until the page is refreshed

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug6662040_1731379052671.Recording__934.mp4

View all open jobs on GitHub

Issue Owner

Current Issue Owner: @luacmartins

[melvin-bot]

Triggered auto assignment to @CortneyOfstad (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]

Triggered auto assignment to @techievivek (DeployBlockerCash), see https://stackoverflowteams.com/c/expensify/questions/9980/ for more details.

[melvin-bot]

💬 A slack conversation has been started in #expensify-open-source

[github-actions]

👋 Friendly reminder that deploy blockers are time-sensitive ⏱ issues! Check out the open `StagingDeployCash` deploy checklist to see the list of PRs included in this release, then work quickly to do one of the following:

1. Identify the pull request that introduced this issue and revert it.
2. Find someone who can quickly fix the issue.
3. Fix the issue yourself.

[techievivek]

@luacmartins seems related to the search functionality, can you please take care of it?

[luacmartins]

It doesn't seem like we push any Onyx updates from UnapproveExpenseReport command so that's why Search gets out of sync. @Beamanator can you confirm that since it seems like you worked on this command?

[luacmartins]

I'll demote this to NAB since the fix would be in Auth

[luacmartins]

@CortneyOfstad I'll unassign you since this issue is resolved by a revert. I'll keep it open to make sure I fix it in my v2 PR.

[luacmartins]

hmm I see that the Onyx update for UnapproveExpenseReport is the following:

According to this SO, stateNum 1 and statusNum 3 isn't a valid combo. I'll take a look there

[luacmartins]

Before I investigate Auth, it seems like the data in snapshot_ is not being updated, since it's still at stateNum 2 and statusNum 3 after unapproving. Even if the Auth response is incorrect, we should be updating it to 1 and 3 like shown above. So I'll investigate that first

[luacmartins]

Interesting, so after unapproving a report we merge the following changes to the Search data, the first which correctly updates the report state/status to 1, but then there's another merge that reverts that back to 2/3

[info] [Onyx] merge called for key: snapshot_243428839 changes: {"data":{"report_4218805946655093":{"chatReportID":"4713946710220241","chatType":"","currency":"USD","isWaitingOnBankAccount":false,"managerID":1175,"nonReimbursableTotal":0,"ownerAccountID":1175,"policyID":"B8110BD941FBBECF","private_isArchived":"","reportID":"4218805946655093","reportName":"Expense Report #4218805946655093","stateNum":1,"statusNum":1,"total":-100,"type":"expense","unheldTotal":-100}}} properties: data hasChanged: true - "" 
[info] [Onyx] merge called for key: snapshot_243428839 changes: {"data":{"report_4218805946655093":{"chatReportID":"4713946710220241","chatType":"","currency":"USD","isWaitingOnBankAccount":false,"managerID":1175,"nonReimbursableTotal":0,"ownerAccountID":1175,"policyID":"B8110BD941FBBECF","private_isArchived":"","reportID":"4218805946655093","reportName":"Expense Report #4218805946655093","stateNum":2,"statusNum":3,"total":-100,"type":"expense","unheldTotal":-100},"personalDetailsList":{"1175":{"accountID":1175,"avatar":"https://d2k5nsl2zxldvw.cloudfront.net/images/avatars/default-avatar_24.png","displayName":"test","firstName":"test","lastName":"","login":"[email protected]","phoneNumber":"","pronouns":"","status":null,"timezone":{"automatic":true,"selected":"America/Edmonton"},"validated":false}},"report_4713946710220241":{}}} properties: data hasChanged: true - "" 
[info] [Onyx] merge called for key: snapshot_243428839 changes: {"data":{"report_4218805946655093":{},"personalDetailsList":{"1175":{"accountID":1175,"avatar":"https://d2k5nsl2zxldvw.cloudfront.net/images/avatars/default-avatar_24.png","displayName":"test","firstName":"test","lastName":"","login":"[email protected]","phoneNumber":"","pronouns":"","status":null,"timezone":{"automatic":true,"selected":"America/Edmonton"},"validated":false}}}} properties: data hasChanged: false - "" 

[luacmartins]

Ah I see. Every time we call UnapproveExpenseReport we also seem to call GetMissingOnyxMessages which has the following update, which revert the changes:

[luacmartins]

Pinging @Beamanator for some clarification on how UnapproveExpenseReport is sending those updates and why we call GetMissingOnyxMessages since I couldnt find where Auth/Web-E sends that data

[melvin-bot]

The solution for this issue has been 🚀 deployed to production 🚀 in version 9.0.61-3 and is now subject to a 7-day regression period 📆. Here is the list of pull requests that resolve this issue:

• [CP Staging] Revert "Show search action buttons" #52434

If no regressions arise, payment will be issued on 2024-11-21. 🎊

[melvin-bot]

@luacmartins @luacmartins The PR fixing this issue has been merged! The following checklist (instructions) will need to be completed before the issue can be closed. Please copy/paste the BugZero Checklist from here into a new comment on this GH and complete it. If you have the K2 extension, you can simply click: [this button]

[Beamanator]

Hmm so Auth-wise:

1. I'm sure that Report::createAction does its own onyx-update-sending, you just have to follow the chain down a few levels.
2. For auth.report.updateLastReadTime It looks like that just calls setReportNameValuePair which has its own onyx-update-queueing
3. Then for ReportAction::createOrUpdateReportPreview it calls the above two functions, OR queueReportPreviewMessageUpdates which does its own queueing

Looks like there's nothing in Web-E helping with Onyx updates

[melvin-bot]

⚠️ Looks like this issue was linked to a Deploy Blocker here

If you are the assigned CME please investigate whether the linked PR caused a regression and leave a comment with the results.

If a regression has occurred and you are the assigned CM follow the instructions here.

If this regression could have been avoided please consider also proposing a recommendation to the PR checklist so that we can avoid it in the future.

[melvin-bot]

Reviewing label has been removed, please complete the "BugZero Checklist".

[melvin-bot]

The solution for this issue has been 🚀 deployed to production 🚀 in version 9.0.66-8 and is now subject to a 7-day regression period 📆. Here is the list of pull requests that resolve this issue:

• Show search action buttons v2 #52441

If no regressions arise, payment will be issued on 2024-12-03. 🎊

[melvin-bot]

@luacmartins @luacmartins The PR fixing this issue has been merged! The following checklist (instructions) will need to be completed before the issue can be closed. Please copy/paste the BugZero Checklist from here into a new comment on this GH and complete it. If you have the K2 extension, you can simply click: [this button]

[luacmartins]

This is done