You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Web - Payment details is missing after Split Money when you click on green badge icon #3940
After Split Request is done select user which you requested money.
Click on Green Badge Icon
Expected Result:
Payment details should be displayed
Actual Result:
Payment details is missing after Split Money when you click on green badge icon.
Workaround:
n/a
Platform:
Where is this issue occurring?
Web ✔️
iOS
Android
Desktop App
Mobile Web
Version Number: Build: 1.0.79-0 Logs:https://stackoverflow.com/c/expensify/questions/4856 Notes/Photos/Videos: Any additional supporting documentation
OS and browser used: Chrome
Is the issue reproducible in Prod: No
👋 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:
Identify the pull request that introduced this issue and revert it.
I'm able to reproduce this on Production, on version 1.0.75-5, @mvtglobally what version on production were you unable to reproduce this on (1.0.79-0 doesn't exist yet)? I did notice that after splitting the bill, one of the two accounts did show the details properly when pressing the green badge icon.
If you look at the URL bar, you can see that the URL is showing a duplicate reportID for the account that isn't showing the details, which seems to be the IOUReportID. So normally the URL would be expensify.cash/iou/details/chatReportID/IOUReportID, but in this case we're seeing expensify.cash/iou/details/IOUReportID/IOUReportID.
After doing some logging it seems that after all the requests finish the reportIOUs_ value for the IOUReportID have the chatReportID set to the IOUReportID, so there must be a place where that value is getting set incorrectly in Onyx.
Looks like the issue is that we're passing in the IOUReportID to getSimplifiedIOUReporthere, when we should be passing the chatReportID. Going to remove the deployBlocker on this one, but since I sorted it out I'll make a PR and handle this one.
Activity
MelvinBot commentedon Jul 9, 2021
Triggered auto assignment to @CortneyOfstad (
AutoAssignerTriage), see https://stackoverflow.com/c/expensify/questions/4749 for more details.MelvinBot commentedon Jul 9, 2021
Triggered auto assignment to @cead22 (
Engineering), see https://stackoverflow.com/c/expensify/questions/4319 for more details.OSBotify commentedon Jul 9, 2021
👋 Friendly reminder that deploy blockers are time-sensitive ⏱ issues! Check out the open
StagingDeployCashdeploy checklist to see the list of PRs included in this release, then work quickly to do one of the following:Jag96 commentedon Jul 9, 2021
I'm able to reproduce this on Production, on version 1.0.75-5, @mvtglobally what version on production were you unable to reproduce this on (1.0.79-0 doesn't exist yet)? I did notice that after splitting the bill, one of the two accounts did show the details properly when pressing the green badge icon.
If you look at the URL bar, you can see that the URL is showing a duplicate reportID for the account that isn't showing the details, which seems to be the IOUReportID. So normally the URL would be
expensify.cash/iou/details/chatReportID/IOUReportID, but in this case we're seeingexpensify.cash/iou/details/IOUReportID/IOUReportID.After doing some logging it seems that after all the requests finish the
reportIOUs_value for the IOUReportID have the chatReportID set to the IOUReportID, so there must be a place where that value is getting set incorrectly in Onyx.Looks like the issue is that we're passing in the IOUReportID to
getSimplifiedIOUReporthere, when we should be passing the chatReportID. Going to remove the deployBlocker on this one, but since I sorted it out I'll make a PR and handle this one.isagoico commentedon Jul 12, 2021
Issue not reproducible during KI retests (First Week)
Jag96 commentedon Jul 21, 2021
This has been fixed by #3946, closing