/root/Routes-api on 31.97.228.132 is not a git repository. Work had been
done directly on the box and existed nowhere else -- a single rm -rf from
being lost, and impossible to review or roll back.
Deploying the previous HEAD over it would have silently reverted all of
this. Most visibly the Valhalla road-backend probe in main.py, whose own
comment explains why it exists: road sequencing degrades to aerial
silently by design, so an unreachable backend stays invisible, "which is
exactly how the expired Google key went unnoticed". Overwriting it would
have reintroduced precisely the failure it was written to catch, and the
service would have kept answering 200 throughout.
The server had also moved from Google Maps to Valhalla for road distance
(VALHALLA_URL, road_backend_status, +190 lines in route_optimizer),
extended docker-compose from 44 to 95 lines, and changed rider fetching,
health, dynamic config and the cache layer.
Only 10 files differ in substance. The other 27 that appeared to differ
were CRLF-vs-LF noise -- the server writes CRLF -- and are normalised to
LF here rather than committed as spurious whole-file rewrites.
Committed as-is, before any change of mine, so the diff that follows is
reviewable against what is actually running.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
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>
