Repository navigation
Held expense - Header subtitle in system message thread opens not here page when holding fails #46673
Description
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.0.15-5
Reproducible in staging?: Y
Reproducible in production?: N
If this was caught during regression testing, add the test name, ID and link from TestRail: N/A
Issue reported by: Applause - Internal Team
Action Performed:
Precondition:
- User A and B have no unsettled expense
- Go to staging.new.expensify.com
- [User A] Submit an expense to User B
- [User A] Click on the preview in the main chat to go to combined report
- [User A] Click on the report header > Hold
- [User A] Leave Hold RHP open
- [User B] Pay the expense
- [User A] Enter a reason to hold and save it
- [User A] Right click on "held this expense" system message > Reply in thread
- [User A] Click on the header subtitle
Expected Result:
App will redirect to the transaction thread when clicking on the header subtitle (production behavior)
Actual Result:
App opens not here page when clicking on the header subtitle
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
Activity
melvin-bot commentedon Aug 1, 2024
Triggered auto assignment to @Beamanator (
DeployBlockerCash), see https://stackoverflowteams.com/c/expensify/questions/9980/ for more details.github-actions commentedon Aug 1, 2024
👋 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:
lanitochka17 commentedon Aug 1, 2024
We think that this bug might be related to #wave-collect - Release 1
lanitochka17 commentedon Aug 1, 2024
Production:
Recording.2273.mp4
Beamanator commentedon Aug 1, 2024
Logs - error:
Beamanator commentedon Aug 1, 2024
Marking this NAB b/c it's probably a pretty uncommon flow (marking a request as HOLD while it justtt got paid)
cc @robertjchen just to make sure you agree this shouldn't be a blocker
Beamanator commentedon Aug 1, 2024
I think we should figure out how to send the appropriate onyx data to the client which tried holding. OR we may actually not need to do anything in the front end, since "ideally" the onyx update from the other person (who paid the money request) should be on its way... What do you think @robertjchen ?
melvin-bot commentedon Aug 6, 2024
@Beamanator Eep! 4 days overdue now. Issues have feelings too...
Beamanator commentedon Aug 6, 2024
Bump @robertjchen - maybe I'll assign you, hope you don't mind :D
robertjchen commentedon Aug 7, 2024
Thanks, I can handle
robertjchen commentedon Aug 8, 2024
Finally got a chance to look into this in detail. Yeah, this is definitely an interesting corner case 🤔.
Yes, there's a bit of a delay with the pay/approve operations since those operations do a bit of work behind the scenes and opens up this gap of time when this could happen. The report being viewed by the holder is deleted/re-created with a new optimistic ID as part of the process...
Maybe if the hold request fails, we can kick the user out of the report? 🤷 I'm leaning toward :donothing: for now- let's revisit if it becomes an issue during real-world usage?