Bug #3781
Pick-up location is wrong while redirecting to the MAP.
Added by Shalu T S over 1 year ago.
Updated 10 months ago.
Due date:
12/05/2024 (about 16 months late)
Milestone:
Sprint 19 Tukxi Ride 2024 May 01 to May 31
Branch name:
sprint-19_sreedevi_3781
Description
Pick-up location is wrong while redirecting to the MAP. The rider makes a trip request from "Thapasaya info park" (rider location) with the pick-up point "Athani" and destination as "Alakapuri.". But after accepting and redirecting to the map, the pick-up location is showing as "Thapasaya info park."
Trip ID: 17332227841166
Files
- Due date set to 12/05/2024
- Status changed from New to In Progress
- Assignee changed from Rahul C R to Sreedevi K S
- Milestone deleted (
Backlog)
- Milestone set to Sprint 19 HHPortal 2023 May 01 to May 31
- Milestone deleted (
Sprint 19 HHPortal 2023 May 01 to May 31)
- Milestone set to Sprint 19 Tukxi Ride 2024 May 01 to May 31
- Branch name set to sprint-19_sreedevi_3781
I have thoroughly investigated the bug regarding the incorrect pick-up location displayed on the map. Over the past few days, I have analyzed the flow of parameters passed to the sendRequestToDrivers API, including message (CabRequestedJson), PickupLatitude, PickupLongitude, and PickupAddress. The pickUpLocation variable, which is declared globally, is assigned values based on multiple conditions, such as matching the current location, search inputs, or saved addresses like work or home. Despite extensive debugging and testing, I have been unable to reproduce the issue on the development side. The overwritten value of pickUpLocation seems to occur under rare and highly specific conditions that are difficult to replicate.
Additionally, I reviewed the push notification payload provided by the backend team from the QA reproduction case, which confirms that the correct latitude and longitude for the pick-up (Athani) and destination (Alakapuri) were passed. This suggests that the issue may not lie within the current code logic. Given the rarity of this occurrence and the lack of reproducibility, I believe this issue might require further investigation or additional context to identify external factors contributing to the behavior. Please advise on the next steps or any additional information that might help in resolving this rare scenario.
- Status changed from In Progress to Resolved
Found out the issue is from the backend side...
- Status changed from Resolved to Reopened
Add Logger code to the branch in Driver for testing in driver
- Status changed from Reopened to Resolved
- Status changed from Resolved to QA Ready
Also available in: Atom
PDF