[Payment Due 18 March] [$500] Cancel payment - Cancellation is not updated in real time when it is not the latest request

[m-natarajan]

If you haven’t already, check out our contributing guidelines for onboarding and email contributors@expensify.com to request to join our Slack channel!

---

Issue found when executing #34719
Version Number: 1.4.42-1
Reproducible in staging?: Y
Reproducible in production?: New feature
If this was caught during regression testing, add the test name, ID and link from TestRail:
Email or phone of affected tester (no customers):
Logs: https://stackoverflow.com/c/expensify/questions/4856
Expensify/Expensify Issue URL:
Issue reported by: Applause internal team
Slack conversation:

Action Performed:

1. [Member] Request money in workspace chat.
2. [Admin} Pay elsewhere the request.
3. [Admin] Cancel the payment.
4. Note that the payment cancellation is updated in real time for Member.
5. [Admin] Pay the request again.
6. [Member] Create a second request.
7. [Admin} Pay elsewhere the second request.
8. [Admin] Go to the first paid request report in Step 2.
9. [Admin] Cancel the payment.

Expected Result:

The payment cancellation will be updated for Member in real time.

Actual Result:

The payment cancellation is not updated in real time for Member when the cancelled payment is not the latest request.
It is only updated when the page is refreshed.

Workaround:

unknown

Platforms:

Which of our officially supported platforms is this issue occurring on?

• Android: Native
• Android: mWeb Chrome
• iOS: Native
• iOS: mWeb Safari
• MacOS: Chrome / Safari
• MacOS: Desktop

Screenshots/Videos

Add any screenshot/video evidence

Bug6381966_1708094751882.20240216_215231.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~01e56b494e59933461
• Upwork Job ID: 1758506999222018048
• Last Price Increase: 2024-02-16

Issue Owner

Current Issue Owner: @Gonals

[melvin-bot]

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

[melvin-bot]

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

[melvin-bot]

Triggered auto assignment to @laurenreidexpensify (Bug), see https://stackoverflow.com/c/expensify/questions/14418 for more details.

[m-natarajan]

@laurenreidexpensify FYI I haven't added the External label as I wasn't 100% sure about this issue. Please take a look and add the label if you agree it's a bug and can be handled by external contributors.

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

[m-natarajan]

We think this might be related to #wave5-free-submitters
cc @dylanexpensify

[melvin-bot]

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

[pecanoro]

Ok, I was able to reproduce. Let me find who implemented this functionality since it's a new feature so we can get some context.

[pecanoro]

It's coming from this #34719. It is probably caused because we are forgetting to send some pusher events to the submitter when cancelling the request or sending the wrong one.

[Gonals]

It's coming from this #34719. It is probably caused because we are forgetting to send some pusher events to the submitter when cancelling the request or sending the wrong one.

Yep. That's likely it. I don't think we need to block/revert on this, as it is a backend issue, and not very problematic. I'll work on a fix today, though

[Beamanator]

I agree with calling this NAB

[melvin-bot]

Current assignee @jjcoffee is eligible for the Internal assigner, not assigning anyone new.

[Gonals]

I'm actually not able to reproduce this. The message is getting updated in real time for me. @m-natarajan, can you give it another shot?

[pecanoro]

@Gonals Maybe it's easier if you post in the qa channel to get another test of this.

[laurenreidexpensify]

Posted - https://expensify.slack.com/archives/C9YU7BX5M/p1708590138119879

[kavimuru]

@laurenreidexpensify @pecanoro

There is one step is missing in the OP. Edited the OP and updating here too. Issue is still reproducible.

1. [Member] Request money in workspace chat.
2. [Admin} Pay elsewhere the request.
3. [Admin] Cancel the payment.
4. Note that the payment cancellation is updated in real time for Member.
   5. [Admin] Pay the request again. This step was missing in the OP
5. [Member] Create a second request.
6. [Admin} Pay elsewhere the second request.
7. [Admin] Go to the first paid request report in Step 2.
8. [Admin] Cancel the payment.

20240222_213346.mp4

[melvin-bot]

@pecanoro, @Gonals, @jjcoffee, @laurenreidexpensify Whoops! This issue is 2 days overdue. Let's get this updated quick!

[Gonals]

I'll take another look on Monday!

[melvin-bot]

@pecanoro, @Gonals, @jjcoffee, @laurenreidexpensify Whoops! This issue is 2 days overdue. Let's get this updated quick!

[Gonals]

Things got in the way. I'll retest this tomorrow!

[Gonals]

Ok, I think I have been able to reproduce. Investigating

[Gonals]

Ok, I think I have been able to reproduce. Investigating

The reportAction does get updated correctly. It is just the IOU preview that fails to update automatically. I think I found the problem in-code. PR incoming

[melvin-bot]

@pecanoro, @Gonals, @jjcoffee, @laurenreidexpensify Uh oh! This issue is overdue by 2 days. Don't forget to update your issues!

[laurenreidexpensify]

This is on staging

[melvin-bot]

@pecanoro, @Gonals, @jjcoffee, @laurenreidexpensify Still overdue 6 days?! Let's take care of this!

[laurenreidexpensify]

On prod now, let's pay this on 18 March

[melvin-bot]

@pecanoro, @Gonals, @jjcoffee, @laurenreidexpensify 8 days overdue is a lot. Should this be a Weekly issue? If so, feel free to change it!

[jjcoffee]

Unassigning as no C+ was required here.