f804791864
POST /api/v1/optimization/doormile/sequence. Same optimizer, same riders, same kitchens, same step semantics as the provider flow -- it only differs in the shape of the payload. Doormile keys on bookingid and sends pickuplatitude; the provider flow keys on deliveryid and sends pickuplat. Rather than making Doormile translate itself into jupiter's vocabulary on the way in and back out, it gets an endpoint in its own terms. The routing is not reimplemented: this maps onto the internal shape, calls the same optimize_provider_payload, and maps back. start_coords is passed through, so a run starts from the kitchen instead of being inferred from whichever stop happens to be first. /optimization/createdeliveries is deliberately untouched -- jupiter is live on it and tightening its body would break real deliveries. But that endpoint takes list[dict], so a payload with the wrong field names returns HTTP 200 "Success" with every coordinate defaulted to 0.0, no reordering and all distances zero. Nothing depends on the new endpoint yet, so it validates strictly and rejects that outright. It also rejects 0,0 coordinates: inside the valid range, but a point in the Atlantic that drags an entire route toward it. Single stop short-circuits to step 1 rather than spending an OR-Tools solve. Duplicate bookingids are refused, since results are keyed back by bookingid and a duplicate makes the caller's mapping ambiguous. Steps for bookings the caller never sent are dropped -- callers write these onto their own rows. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
6.7 KiB
6.7 KiB