fix(fleetops): drive the order activity cycle the way a client does - #40
Merged
Merged
Conversation
Complete an Order answered "Not all waypoints completed for order." — correctly.
completeOrder requires every waypointMarker at COMPLETED, and nothing in the
collection advanced them.
The pieces were all present but inert:
Update Order Activity sent only {"skip_dispatch": false}. updateActivity reads
$request->array('activity'), so with none supplied it could never advance a
service stop. It now sends the activity, which is what navigator-app sends —
order.updateActivity({ activity }) in OrderScreen.
Get Order Next Activity captured nothing and was not scoped to a stop.
getNextActivity resolves service-stop activities only when a `waypoint` is
supplied; without one it returns the order-level lifecycle activity. It now
passes the current destination and captures the first activity returned.
Neither tracked the destination. Applying an activity that completes the current
stop advances the order to the next, so Start an Order seeds
{{current_waypoint_id}} from payload.current_waypoint and Update Order Activity
re-reads it.
This mirrors navigator-app exactly: getNextActivity({ waypoint }) then
updateActivity({ activity }), once per stop. The collection's order carries four
waypoints plus pickup and dropoff, so the contract run cycles the pair — see the
runner change in fleetbase/fleetbase.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Complete an Orderanswered "Not all waypoints completed for order." — correctly.completeOrderrequires everywaypointMarkeratCOMPLETED, and nothing in the collection ever advanced them.The pieces were all present but inert:
Update Order Activity{"skip_dispatch": false}.updateActivityreads$request->array('activity'), so with none supplied it could never advance a service stop.Get Order Next ActivitygetNextActivityresolves service-stop activities only when awaypointis supplied; without one it returns the order-level lifecycle activity.Now
Start an Orderseeds{{current_waypoint_id}}frompayload.current_waypoint.Get Order Next Activitypasses it as?waypoint=and captures the first activity returned.Update Order Activitysends that activity, and re-reads the destination the order advanced to.This mirrors
navigator-appexactly —getNextActivity({ waypoint: destination.id })thenupdateActivity({ activity }), once per stop (src/screens/OrderScreen.tsx).The collection's order carries four waypoints plus pickup and dropoff, so the contract run cycles the pair rather than calling it once; that ordering change is in fleetbase/fleetbase.
Sending the activity is what a real client sends, so the published example is now correct rather than merely harmless.
🤖 Generated with Claude Code