[HOLD for payment 2024-12-03] [Search v1.2] - Unable to pay held expense in Search

[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:
Email or phone of affected tester (no customers): [email protected]
Issue reported by: Applause Internal Team

Action Performed:

Precondition:

• User has paid expense in Search before.

1. Go to staging.new.expensify.com
2. [User A] Submit an expense to User B.
3. [User B] Go to transaction thread > Click report header.
4. [User B] Click Hold expense, enter reason and save it.
5. [User B] Go to Search.
6. [User B] Click Pay button for the held expense.

Expected Result:

Confirmation modal will show when paying held expense in Search.

Actual Result:

Confirmation modal does not show when paying held expense in Search. The pay button shows loading and then reverts to initial state.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug6661871_1731361819203.20241112_054704.mp4

View all open jobs on GitHub

Issue Owner

Current Issue Owner: @OfstadC

[melvin-bot]

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

[melvin-bot]

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

💬 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.

[iwiznia]

Feature was added in this PR #51445

@IuliiaHerets was this issue open while testing that PR? If so, you should've noted that, so the assigned person does not need to go find it.

ccing @luacmartins because it's your PR, but looking into it now.

[iwiznia]

I can't reproduce this... I see the RHP opening:

[iwiznia]

Yeah, still can't reproduce it, even in a new workspace... @IuliiaHerets can you retry? Is there any added context on the test you did that might be triggering this bug?

[luacmartins]

I think the reason applause can reproduce is because for the pay action we only do a "one-click pay" if you have previously paid something in that workspace, which saves that payment method to nvp_private_lastPaymentMethod. Otherwise, we open the RHP.

[iwiznia]

AHA! You are right!

[luacmartins]

I'm still working on adding RBR to Search actions (see this PR). I'll also discuss what the pattern for reports with held expenses should be and come back here.

[iwiznia]

This is the onyxData response I see for the PayMoneyRequestOnSearch command:

"onyxData": [
        {
            "key": "snapshot_243428839",
            "onyxMethod": "merge",
            "value": {
                "data": {
                    "report_5844620916720344": {
                        "hasError": true
                    }
                }
            }
        }
    ],

RequestID 8e17e0714834fb86-POA and logs here. Weird because there's no error there and it returned 200, not sure why it says "hasError": true but also not sure why the button to pay is still there.

[iwiznia]

Must've entered this if but it is completely impossible to know what happened since the https requests are not linked to this one.
@lakchote I see you worked on this command, do you know what could be going on? Also, I think we should pass the requestID to the https request, so logs are all tied to the same requestID.
Going to try to find it by other data

[iwiznia]

Could not find it. Tried this and don't see it here either.

@luacmartins @lakchote I think this should not block newDot deploy anyway since seems like the problem is in the backend, no?

[luacmartins]

Yea, I don't think this is a blocker since the fix is in the backend. We're still working on sending correct Onyx updates from the backend (see this comment)

[iwiznia]

if we are working on it on that other issue, should we close this one?

[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]

[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]

[melvin-bot]

Skipping the payment summary for this issue since all the assignees are employees or vendors. If this is incorrect, please manually add the payment summary SO.

[luacmartins]

Done!