The legacy dual-write leg posted to https://updates.bsky.app/v1/upload. That
hostname has resolved to denis on EKS since the 2026-07-26 origin flip, and denis
deliberately has no /v1/upload route -- publishing there is out-of-band via
`denis publish`. The first OTA publish attempted after the flip therefore got a
404 (run 30220289826).
Point it at ota1's own origin instead. The dual-write was never independent of
the cutover: it wrote to ota1 *through the hostname being cut over*, so flipping
the origin necessarily broke it. Addressing ota1 directly is what the step always
meant. Verified reachable: ota1.us-east.updates.bsky.network/v1/upload returns
401 (route present, auth required) where updates.bsky.app returns 404.
Also reorder the two publishes so denis goes first. This is the more serious half
of the bug. The legacy step ran before the denis steps, so when it 404'd the
three denis steps were skipped and the bundle reached NEITHER origin -- a
dual-write that takes down the working path when its deprecated half fails is
worse than no dual-write. denis is the sole origin serving clients, so it
publishes first; the legacy upload follows and is still required to pass, so a
stale ota1 remains a loud failure rather than a silent one.
The upload URL is now overridable via OTA1_ORIGIN, and the comment explains why
it must never be set back to the CDN hostname.
Both halves go away together when ota1 is decommissioned (Phase 5).
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Austin McKinley
952a176c83