Chunked blob uploads kept the in-progress session in process memory keyed by
upload UUID, so the POST/PATCH/PUT of a single `docker push` had to land on the
same replica. In production the API runs at minReplicas 2 with no session
affinity, so a real push (which streams the layer via PATCH then finalises with
PUT) intermittently 404s with BLOB_UPLOAD_UNKNOWN when chunks hit a replica that
never saw the POST.
- Stage chunked uploads in object storage under uploads/<uuid> instead of an
in-memory temp file. The UUID travels in the Location URL handed to the
client, so any replica reconstructs the staging key with no shared in-process
state. Finalise streams the staged bytes plus any trailing PUT body through
the CAS in one pass; monolithic uploads are unchanged.
- Support DELETE of an in-progress upload (cancel) by dropping its staging
object.
- Reap abandoned staging objects in the GC (uploads/ older than 24h) via a new
S3 ListStaleObjects, so cancelled/interrupted pushes don't leak.
Verified by splitting a single push across two instances sharing one
Postgres+MinIO: POST->A, PATCH->B, PUT->A finalises and the blob pulls back
byte-identical from both. The dockerised e2e suite still passes.
unkinben
f9f78955e6