-
Notifications
You must be signed in to change notification settings - Fork 2.9k
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-10-30] [$250] Distance - Waypoints are not correctly ordered in generated eReceipt #29621
Comments
Triggered auto assignment to @conorpendergrast ( |
Bug0 Triage Checklist (Main S/O)
|
👋 Friendly reminder that deploy blockers are time-sensitive ⏱ issues! Check out the open
|
Triggered auto assignment to @marcochavezf ( |
Job added to Upwork: https://www.upwork.com/jobs/~01c57e39dd4e2e4a50 |
Triggered auto assignment to Contributor-plus team member for initial proposal review - @situchan ( |
This is a new feature and i dont think this has to be blocker, its not ideal experience but i think we can fix this in a quick follow up @neil-marcellini @arosiclair rather then hold deploy on this fix. |
Upwork job price has been updated to $250 |
Posted in wave5 for visibility in case someone from the distance req team wants to take it over |
Ah I think this is a backend problem where we aren't sorting the waypoints by key when creating the request and assuming that they are in order. JSON doesn't guarantee that they are in order and clearly they are not. I can tell because the route image shows the waypoints out of order. I'll work on a fix soon. |
Current assignee @situchan is eligible for the Internal assigner, not assigning anyone new. |
Here are a bunch of waypoints that reproduce the problem. Waypoints{
"waypoint0": {
"lat": 37.9004816,
"lng": -122.6444263,
"address": "Stinson Beach, CA 94970, USA"
},
"waypoint1": {
"lat": 37.8652634,
"lng": -122.3111483,
"address": "Berkeley Marina, Berkeley, CA, USA"
},
"waypoint2": {
"lat": 37.8064291,
"lng": -122.4506915,
"address": "Crissy Field East Beach, San Francisco, CA 94129, USA"
},
"waypoint3": {
"lat": 37.8727428,
"lng": -122.4554066,
"address": "Tiburon, CA 94920, USA"
},
"waypoint4": {
"lat": 37.9445266,
"lng": -122.5086664,
"address": "Larkspur, CA 94939, USA"
},
"waypoint5": {
"lat": 37.8974259,
"lng": -122.4885845,
"address": "Blackies Pasture, Tiburon, CA 94920, USA"
},
"waypoint6": {
"lat": 36.6002378,
"lng": -121.8946761,
"address": "Monterey, CA, USA"
},
"waypoint7": {
"lat": 37.8309974,
"lng": -122.2919998,
"address": "4400 Shellmound St, Emeryville, CA 94608, USA"
},
"waypoint8": {
"lat": 37.9435872,
"lng": -122.5405003,
"address": "800 Magnolia Ave, Larkspur, CA 94939, USA"
},
"waypoint9": {
"lat": 37.6191671,
"lng": -122.3816108,
"address": "San Francisco, CA 94128, USA"
},
"waypoint10": {
"lat": 37.7156188,
"lng": -122.2143079,
"address": "1 Airport Dr, Oakland, CA 94621, USA"
},
"waypoint11": {
"lat": 37.7935724,
"lng": -122.483638,
"address": "Baker Beach, San Francisco, CA, USA"
}
} |
The waypoint ordering problem is fixed with a very simple change on the front end. However I also noticed that the eReceipt and image weren't loading properly sometimes, so I'm planning to fix that in the same PR. |
Up for review! |
|
The solution for this issue has been 🚀 deployed to production 🚀 in version 1.3.88-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-10-30. 🎊 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:
|
Let's skip the C+ checklist, as this is a brand new feature for now |
All done! |
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: 1.3.84-0
Reproducible in staging?: Yes
Reproducible in production?: No
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:
Issue found when executing PR #27204
Action Performed:
Expected Result:
The generated eReceipt should have all points ordered as they were entered at the time of request
Actual Result:
The generated eReceipt does not have the points correctly ordered
Workaround:
Unknown
Platforms:
Which of our officially supported platforms is this issue occurring on?
Screenshots/Videos
Android: Native
Android: mWeb Chrome
iOS: Native
iOS: mWeb Safari
Bug6237159_1697299785737.1697239013123_Apss5121_1_.mp4
MacOS: Chrome / Safari
MacOS: Desktop
Windows: Chrome
Bug6237159_1697299785763.bandicam_2023-10-13_19-01-26-241.mp4
View all open jobs on GitHub
Upwork Automation - Do Not Edit
The text was updated successfully, but these errors were encountered: