> [!important] Closed Beta blocker: broken main path (slow uploads lose their response) > A handler that arms the read deadline alone leaves the connection write deadline at `server.timeouts.write`, `10s` by default, so an upload that outlasts that window is stored server side and answers a `503` reset to the client while the access log records the `201`. Clients retry uploads that already landed. > > Measured on staging 2.23.0 with a Maven artifact `PUT`: a 64 MB file unthrottled (8.3s) returns `201`; the same file throttled to 16.6s and above returns `503`. A 600 MB upload over 76s logs `201, duration_s 75.6` while the client saw `503`. `curl --limit-rate 4M -T` reproduces it, and is the verification case for the fix. > > Where the three arms stand. The OCI blob upload arms read and write together and never had this shape. The Maven artifact `PUT` did, and !2351 closed it (closing #776); that is released in `v2.25.2`, so a staging run needs `v2.25.2` or later to see it. npm publish did too, and !2459 with !2460 closed it as Step 4 of the same plan: `PublishHandler.ServeHTTP` wraps the body in `server.DeadlineReader`, whose constructor pins the write half at the read ceiling. Seeing the npm arm on staging needs the first tag that contains !2460, and as of 2026-09-10 no tag does, because the latest, `v2.29.1`, was cut before that merge. ## Problem The three upload handlers armed the per-request socket read deadline once, before the body read, at `now + <format>.upload_read_timeout`. Nothing re-armed it while bytes were arriving, so the value was a ceiling on the whole transfer rather than a bound on how long the connection may sit idle. The three sites, the sizes they have to cover, and where each one stands: | Site | Knob | Default | Route ceiling | State | | --- | --- | --- | --- | --- | | `oci.UploadHandler.setUploadDeadlines` (`internal/format/oci/upload.go`) | `container.upload_read_timeout` | `1h` | `container.blob_max_size`, `50GB` | re-arms, !2346, `container.upload_inactivity_timeout` | | `maven.dispatchHandler.extendReadDeadline` (`internal/format/maven/upload.go`) | `maven.upload_read_timeout` | `1h` | `maven.max_artifact_size`, `5GB` | re-arms, !2351, `maven.upload_inactivity_timeout` | | `npm.PublishHandler.ServeHTTP` (`internal/format/npm/publish.go`) | `npm.publish_read_timeout` | `30m` | `npm.max_publish_envelope_size`, `6.7GB` | re-arms, !2460, `npm.publish_inactivity_timeout` | A client that keeps sending is cut anyway once the window elapses. At the container defaults, a single blob at the ceiling had to sustain roughly 14 MB/s end to end to finish inside the hour; anything slower was disconnected mid-transfer with the bytes already staged. The same arithmetic described the npm publish route, against its own `30m` window and `6.7GB` cap: roughly 3.7 MB/s sustained. ## What ADR-004 asks for [ADR-004](https://gitlab.com/gitlab-com/content-sites/handbook/-/blob/main/content/handbook/engineering/architecture/design-documents/artifact_registry/decisions/004_data_and_application_limits.md) asks for an inactivity timeout: "Upload sessions are subject to an inactivity timeout. If no data is received within the timeout window, the session is terminated and partially uploaded data is discarded." That sentence is about upload **sessions**, and the session half is a separate, smaller gap: `upload_sessions.expires_at` was stamped once at creation and never refreshed. While the MR for the session half is open, the window still runs from `created_at`; once it merges, a persist carrying new bytes moves the window and an empty one does not. That MR is [!2215](https://gitlab.com/gitlab-org/ops/artifact-registry/-/merge_requests/2215), and it does not touch the socket deadline this issue is about. ## Fix Re-arm the read deadline as bytes arrive, rather than once before the read. The shape that does this without threading a reset into every response path is a reader wrapper: `server.DeadlineReader` (`internal/server/upload_deadline.go`), installed around the request body at the sites above. Both questions this issue opened are settled in [the upload-inactivity-deadline plan](https://gitlab.com/gitlab-org/ops/artifact-registry/-/blob/main/docs/plans/2026-09-03-upload-inactivity-deadline.md), merged as !2301: 1. **What the three configuration keys mean.** The existing `*_read_timeout` keys keep their meaning as an absolute ceiling, and a new `*_inactivity_timeout` key lands beside each one to size the gap between reads. Without a ceiling, a client sending one byte per window holds the connection for as long as the size cap allows, and `MaxBytesReader` does not bound that. All three keys exist, each defaulting to `5m`: `container.upload_inactivity_timeout` (`internal/config/container.go:28`), `maven.upload_inactivity_timeout` (`internal/config/maven.go:20`) and `npm.publish_inactivity_timeout` (`internal/config/npm.go:47`), read at `a951ebf20`. 1. **What happens to the write deadline.** `NewDeadlineReader` arms the write half once, at the ceiling instant the route's own read timeout already set, and leaves it there for the whole request; only the read half re-arms, at `min(now + inactivity, ceilingAt)`. So the re-arming read deadline does not reintroduce the failure #776 describes on a longer timescale. ## Related - #31 covers arming `SetWriteDeadline` alongside `SetReadDeadline` on the npm publish and Maven upload paths, which is the *once* case, not the re-arming one. Its Maven half and #776 describe the same defect. Both of its route halves are armed now, Maven by !2351 and npm by !2460, so it stays open for its S01 spec-text half. `internal/server/body_size.md` carries what is left of it at the route level: because a route's two halves sit on one instant, a read that runs all the way to that instant leaves nothing for the work between the end of the read and the response. - #776 covered the Maven write deadline specifically. Closed by !2351. - #1288 covers npm single-version unpublish, the one npm write route this issue's plan left out: `armUnpublishDeadlines` arms both halves once, at `now + npm.unpublish_read_timeout`, and nothing re-arms the read half. The plan named that exclusion as one of scope rather than of arithmetic. - This issue was split out of #1024, whose two other halves are the `Content-Length` pre-check (closed by !2186) and the session-level window (!2215).