Trip Management Allows Accepting Then Declining the Same Rider

[Swi-ft]

Description

The Trip Management Dashboard allows a driver to first accept a rider, and then later decline them. This behavior is logically inconsistent and may result in confusion or abuse.

Expected Behavior

Once a rider is accepted:

• They should either remain accepted
• Or there should be a specific cancellation flow, not just a toggle back to "declined"

Steps to Reproduce

1. Offer a ride as a driver.
2. View incoming requests and accept a rider.
3. Navigate to the same request and click "Decline".

Actual Result

Rider gets declined after previously being accepted, with no warning or confirmation dialog.

Impact

Medium – leads to poor trust and inconsistent ride confirmations.

[harshitptl21]

The driver should have the ability to accept or reject a ride, and even to cancel after initially accepting, as situations can change.

The idea that "they should either remain accepted" overlooks a practical issue — if the decline option is removed or restricted, a driver who no longer wants to take the ride might simply not show up, which is even worse. In that case, the rider only finds out at the last minute. Having a clear and intentional way to cancel, even after accepting, is better than leaving the rider uncertain or stranded.

That said, while it’s valid to suggest that “there should be a specific cancellation flow, not just a toggle back to ‘declined’”, introducing a full cancellation process could have unintended consequences. It might actually lead to situations where drivers avoid going through the cancellation steps altogether and simply don’t show up, which leaves the rider again uninformed until the last moment

Regarding the concern that "riders get declined after being accepted without warning or confirmation", if you check the Trip section in the app, the rejection is visible if the driver has declined the ride.

[Swi-ft]

-> " It might actually lead to situations where drivers avoid going through the cancellation steps altogether and simply don’t show up"
It is already bad that the rider doesn't get an email or at least a notification about his ride status, now if the driver is toggling between "Accept" and "Decline", the rider is going to experience a very bad experience using the app and coming to the "avoid going through the cancellation steps altogether and simply don’t show up" part, well as a developer a feature should be developed such that these "cancellation steps" are minimal to not cause much of a headache for the user to fill.

-> "which leaves the rider again uninformed until the last moment"
Like I said, he wasn't getting informed about anything before too.

So, blaming the Driver that he/she might not fill the form is not an excuse to not fix the issue

[harshitptl21]

Kindly focus on testing and avoid making suggestions.
The notification feature was not included in the documentation.

[Swi-ft]

-> "Kindly focus on testing and avoid making suggestions."
Exhibit A:- "well as a developer a feature should be developed such that these "cancellation steps" are minimal to not cause much of a headache for the user to fill."

Exhibit B:- "the rider is going to experience a very bad experience using the app"

Exhibit C:- "So, blaming the Driver that he/she might not fill the form is not an excuse to not fix the issue"

These aren't suggestions, these are testing issues 😊