-
Notifications
You must be signed in to change notification settings - Fork 3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[HOLD for payment 2023-09-29] 🟢 [$500] BUG: [distance] request confirmation offline doesn't show TBD #26537
Comments
Triggered auto assignment to @garrettmknight ( |
Bug0 Triage Checklist (Main S/O)
|
Job added to Upwork: https://www.upwork.com/jobs/~01a9f623a65b6c37a2 |
Current assignee @garrettmknight is eligible for the External assigner, not assigning anyone new. |
Triggered auto assignment to Contributor-plus team member for initial proposal review - @Ollyws ( |
@neil-marcellini can give me more details on Expected Result because linked docs is private |
I included all the details I can. The linked part isn't important. |
ProposalPlease re-state the problem that we are trying to solve in this issue.In Offline mode, the MoneyRequestConfirmationList in Distance request should show "TBD" for amount and distance instead of 0.0 Also, the route should be recalculated on coming back online What is the root cause of that problem?
What changes do you think we should make in order to solve the problem?
What alternative solutions did you explore? (Optional) |
ProposalPlease re-state the problem that we are trying to solve in this issue.[distance] request map is cut off after going online What is the root cause of that problem?Considerably there are two problems here.
Even though we don't have access to how much distance the ride is we're still calculating the distance amount here App/src/libs/DistanceRequestUtils.js Line 72 in 7217a18
We can return "TBD" if the
We can do same with
On But while creating if we're offline we won't be having it so the route will be null even if go online which require us to close the modal and go up again. What changes do you think we should make in order to solve the problem?To fix this we need to do two changes. Here in this App/src/components/DistanceRequest.js Line 154 in 7217a18
we need update the logic as below if ((isOffline && _.isEmpty(waypoints)) || !shouldFetchRoute) {
return;
} Which will refetch the request if there are waypoints and we've updated our online status. But this only requires us to come back to the first page again, which won't be the case everytime. To update the useEffect(() => {
// If the network is offline or we have the coordinate we don't need to call the api again.
if (isOffline || !_.isEmpty(coordinates)) return;
Transaction.getRoute(transaction.transactionID, waypoints);
}, [coordinates, isOffline, transaction.transactionID, waypoints]); What alternative solutions did you explore? (Optional)NA @neil-marcellini Please review the proposal. Sorry for the ping if you're not going to review :) |
Will review this asap. |
Thanks for your proposals. |
@Ollyws I think the changes I mentioned for |
If we go online at |
This is the page we want to show TBD and the values, if we don't fetch the route here when the user become online this page doesn't we update values instantly and show?? But with the first proposal we only solve it at the distance screen. But with my solution we fix it in both places. And results are instantly updated. Let me know if you need more context on this @Ollyws . Thanks!! |
I actually found a better solution for the issue without overcomplicating things with App/src/components/DistanceRequest.js Line 92 in 447d216
Replace this line with:
We already do almost all we need to trigger re-fetch, it's just the logic for checking the doesRouteExist is incorrect, because |
@Ollyws Please watch this video to understand the context of my proposal. Kapture.2023-09-05.at.00.05.44.mp4And fetch route when we're back online is being raised in other PR. |
I like the proposal from @paultsimura. It's clear and simple. We can iron out any details in the PR. I'm going to assign him now for urgency @Ollyws. |
Based on my calculations, the pull request did not get merged within 3 working days of assignment. Please, check out my computations here:
On to the next one 🚀 |
Please also take into consideration the translations and copies waiting times + this comment. |
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. |
|
The solution for this issue has been 🚀 deployed to production 🚀 in version 1.3.72-11 and is now subject to a 7-day regression period 📆. Here is the list of pull requests that resolve this issue: If no regressions arise, payment will be issued on 2023-09-29. 🎊 After the hold period is over and BZ checklist items are completed, please complete any of the applicable payments for this issue, and check them off once done.
For reference, here are some details about the assignees on this issue:
As a reminder, here are the bonuses/penalties that should be applied for any External issue:
|
BugZero Checklist: The PR fixing this issue has been merged! The following checklist (instructions) will need to be completed before the issue can be closed:
|
@garrettmknight, @dannymcclain, @Ollyws, @paultsimura, @neil-marcellini Uh oh! This issue is overdue by 2 days. Don't forget to update your issues! |
This was a new feature so no PR caused this issue. I do think a regression test would be helpful here to ensure this functionality continues to work properly in the future, as it's for one of the main flows in the app and it's easy to test for. |
Regression Test Proposal
Do we agree 👍 or 👎 |
Hey @Ollyws @neil-marcellini, should the payment for this issue happen after the Regression Test is approved and added? |
cc @garrettmknight bump for the payments |
Not overdue, waiting for payment |
My bad, y'all. Summary of payments for this issue:
|
Closing! |
If you haven’t already, check out our contributing guidelines for onboarding and email [email protected] to request to join our Slack channel!
Action Performed:
Expected Result:
The distance request amount should show as TBD. The distance field should use TBD for values that aren't available.
From the design doc:
Additionally, after going back online we should fetch the route so that the values can be filled in.
Actual Result:
The amount and miles show as 0
Workaround:
Ignore it
Platforms:
Which of our officially supported platforms is this issue occurring on?
All
Version Number: Unreleased
Reproducible in staging?: Not yet
Reproducible in production?: Not yet
If this was caught during regression testing, add the test name, ID and link from TestRail:
Email or phone of affected tester (no customers): None
Logs: https://stackoverflow.com/c/expensify/questions/4856
Notes/Photos/Videos: Originally reported by
@situchan
in a PR review here
Expensify/Expensify Issue URL: None
Issue reported by: @situchan
Slack conversation: https://expensify.slack.com/archives/C049HHMV9SM/p1693608145841629
View all open jobs on GitHub
Upwork Automation - Do Not Edit
The text was updated successfully, but these errors were encountered: