Bugfix: do not serve freeze/mirror images via the Wave proxy token path#1087
Conversation
Freeze and mirror requests publish the image to the caller's target registry and return a direct registry reference; they are meant to be pulled directly from that registry. However the ephemeral /v2/wt/<token>/ proxy route still resolved and served them for the token TTL. Reject durable (freeze/mirror) requests on the proxy token path so the image can only be pulled directly from the target registry. Status/detail lookups by request id are unaffected. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Point the caller to the direct image reference in the NotFoundException message, and assert the message carries that reference in the test. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
pditommaso
left a comment
pditommaso
left a comment
There was a problem hiding this comment.
Looks good — solid fix. 🙌
I pushed one small follow-up on top: made the rejection message actionable so it points the caller at the direct image reference (must be pulled directly from '<image>') rather than a generic "not available via the proxy", and tightened the test to assert the message carries that reference. Kept the 404 as-is — it's the right registry-conventional code here.
One thing worth a quick sanity check (non-blocking, happy to take offline): the guard is unconditional, but makeResponseV1 still hands V1 (/container-token) freeze clients a wt/<token> URL, whereas makeResponseV2 already returns the direct image. If legacy V1 freeze is still in use anywhere, those pulls would now 404. If V1 freeze is effectively dead, all good — just flagging.
pditommaso
left a comment
pditommaso
left a comment
There was a problem hiding this comment.
Actually the V1 freeze path should be investigate more before merging.
makeResponseV2 already returns the direct target-registry image for freeze/mirror (durable) requests, but makeResponseV1 kept handing back the Wave proxy token url. Since durable images are no longer served via the proxy token path (see RouteHandler), V1 freeze clients pulling via targetImage would 404. Resolve targetImage to the direct image for durable requests on V1 too, matching V2. Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
3 participants
Summary
Bug fix — ensure freeze (and mirror) images are not pulled via Wave.
Freeze and mirror requests publish the image to the caller's target registry and return a direct registry reference; those images are meant to be pulled directly from that registry. However the ephemeral
/v2/wt/<token>/proxy route still resolved and served them for the token's lifetime, leaving Wave in the pull path. This change rejects durable (freeze/mirror) requests on the proxy token path, so a frozen/mirrored image can only be pulled directly from the target registry.Changes
RouteHandler.parse: when awt/<token>request resolves to adurable()request (freeze/mirror), return404instead of routing the proxy pull. Status/detail lookups by request id are unaffected (they do not go through this path).RouteHandlerTest: add coverage asserting freeze and mirror proxy pulls are rejected; existing non-durable resolution cases are unchanged.Testing
RouteHandlerTestpasses 32/32, including the new freeze/mirror rejection cases and the existing non-durable (build/augment/proxy) resolution cases — no regression.🤖 Generated with Claude Code