cb2660a3da
The client was speaking jupiter's provider dialect -- deliveryid, pickuplat, coordinates as strings -- because that was the only endpoint the Route Optimization API offered. rider-bike now has /api/v1/optimization/doormile/sequence, which takes bookingid and pickuplatitude, so the translation layer is gone. The new endpoint validates its body; the provider one cannot, because jupiter is live on it and tightening it would break real deliveries. That matters here: sending the provider endpoint the wrong field names returns HTTP 200 "Success" with every coordinate defaulted to 0.0, no reordering and all distances zero. The Doormile endpoint rejects that outright, and rejects 0,0 coordinates, which are inside the valid range but are a point in the Atlantic that drags a whole route toward it. Responses now come back properly typed, so the loose float/string coercion is deleted rather than kept for a shape that no longer arrives. Tests replaced to match: they run the real client against a stub server and pin the outbound field names, the mapping back onto assignment ids, that steps for assignments we never sent are discarded, that step 0 is not persisted as a position, and that a failed optimise surfaces an error instead of quietly looking like success. Needs rider-bike deployed first; until then sequencing fails best-effort, which leaves bookings assigned but unordered. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>