mirror of
https://tangled.org/evan.jarrett.net/at-container-registry
synced 2026-08-29 04:06:58 +00:00
Evan JarrettandClaude Opus 5
e6959e6dc6
createSession, the app-password getServiceAuth call, and the hold's /.well-known/atproto-did resolution all used http.DefaultClient, which has no timeout. All three run on the /auth/token path, so a slow or unreachable PDS or hold could hold the request open indefinitely, well past Docker's own token-fetch timeout. Give each a bounded client: 15s for createSession, 10s for the app-password getServiceAuth, 10s for the hold DID fetch. All three are safe to cut off — the two GETs are idempotent, and a timed-out createSession only orphans an unused server-side session. The OAuth refresh path deliberately keeps no overall timeout: its POSTs run through refreshDetachTransport and must not be cancelled mid-rotation, which would strand a rotated refresh token. Note holdDIDResolveClient is package-level in pkg/atproto, so the 10s cap applies to every ResolveHoldDID caller, including the GC, Jetstream backfill and hold-health background workers, not only the token path. That is intended (none of them want an unbounded fetch either), but it is a wider blast radius than the token path alone. This bounds three hops, not the whole request: the OAuth getServiceAuth GET and identity resolution are still unbounded, so /auth/token is not yet fully time-boxed. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>