[BUG]: Regression in next-activity logic causing status loops for orders of pickup and dropoff type (without intermediate points)

[spanchenko]

Overview

After upgrading FleetOps to v0.6.50, simple orders (Pickup/Dropoff only) become stuck in a status loop. The GET /v1/orders/{id}/next-activity endpoint incorrectly returns the current activity code (e.g., enroute for Transport order config) as the next activity, preventing drivers from progressing to the next stage (e.g., completed).

Environment

• FleetOps Version: v0.6.50
• Mobile App: Fleetbase Navigator
• Order Type: Transport (Pickup & Dropoff, waypoints_count = 0)

Reproduction Steps

1. Create a standard Transport order with a Pickup and Dropoff.
2. Dispatch the order to a driver.
3. As a driver, start the order (moving orders.status to enroute).
4. The mobile app calls GET /v1/orders/{id}/next-activity?waypoint={pickup_place_public_id}.
5. Observe the API response.

Expected Result

The API should return the next logical activity: completed.

Actual Result

The API returns the current activity: enroute. The driver is prompted to perform the same action repeatedly.

Root Cause Analysis

The investigation reveals a conflict between the new Waypoint Flow logic and the legacy Order Flow update mechanism.

1. Context Switching: In v0.6.50, OrderController::getNextActivity prioritizes the waypoint parameter. If a record exists in the waypoints table for the provided Place ID, the system switches to a Waypoint context.
2. Data Desynchronization: For simple orders, update-activity only updates the orders.status column. The corresponding records in the waypoints table

if ($waypointContext && in_array($childActivity->code, ['created', 'started', 'dispatched'])) {
       return $childActivity->getChildActivities($context);
}

4. The Loop: Because the Waypoint status is "frozen" at created, the logic starts calculating from the beginning of the flow, skips the system statuses, and stops at the first non-system status: driver_enroute_to_pickup. It ignores the fact that the Order is already at this status.

Suggested Resolution

• Ensure that updateActivity synchronizes the status of relevant waypoints even for simple orders.
• OR: Modify getNextActivity to ignore the waypoint context if the order is not a isMultipleDropOrder.
• OR: Update the recursive skip logic in Activity.php to account for the current Order status even when a Waypoint context is provided.

[roncodes]

We are working on a patch for this issue which should be resolved in the next release.