0288fb7af8
Assignment decided who carried a booking but never what order to run several of them in -- the one capability jupiter had that Doormile did not. It turns out we already own the solver: routes.workolik.com is a live in-house Route Optimization API backed by Valhalla road-network routing, not the paid third party I had assumed. This is a client for it, not a solver. internal/routing posts a rider's active stops and writes back step, previouskms, cumulativekms and ETA onto BookingAssignment. HubBatchAssign calls it after committing a batch, which is exactly the case it exists for: a rider used to walk away with several bookings and no order to run them in. GetMilerAssignments now returns sequenced stops in step order, falling back to newest-first for anything unsequenced. Contract discovered by probing the live service -- the OpenAPI schema types the body as a bare object array, so the field names are not documented anywhere. They are pickuplat/pickuplong/deliverylat/ deliverylong, NOT pickuplatitude/deliverylatitude. Sending the wrong names does not fail: it returns HTTP 200 with every coordinate defaulted to "0.0", no reordering and all distances zero. That trap is recorded in a comment so the next person does not lose an afternoon to it. Numeric fields come back inconsistently typed -- previouskms as a number, actualkms and eta as strings, some decimal -- so they are decoded loosely and coerced, with tests pinning the coercion. Steps for deliveryids we did not send are discarded rather than written, so an echoed or stale id cannot reorder another rider's work. Sequencing is best-effort throughout and runs after assignments commit. The optimizer is a separate service over the network; it being down must leave bookings assigned but unordered, never undo the batch. Step 0 means "not sequenced", not "first". Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
5.7 KiB
5.7 KiB