Revisit swallowing context.DeadlineExceeded as "client gone"

Several error paths treat context.Canceled and context.DeadlineExceeded together as "client gone" and return without logging or writing a response:

  • internal/managementapi/resolve.go (logAndWriteInternalError)
  • internal/auth/middleware.go
  • internal/auth/handler_token.go
  • internal/jobsasynq/classifier.go
  • internal/storage/emit.go
  • internal/storage/driver/gcs/gcs.go
  • internal/format/oci/upload.go

Canceled is a genuine client disconnect. DeadlineExceeded, though, can come from a server-side deadline (a handler timeout, a DB statement_timeout, a per-request context deadline). If one is ever set, a real server-side timeout would vanish: no ERROR log for Sentry and, on the API paths, no error envelope to the client. A datastore slowdown would become invisible.

Today none of these paths set a per-request deadline, so this is latent rather than live. It surfaced in the review of !824 (merged) (management API repository update/delete handlers) and was deferred here because it spans the whole codebase, not just the repository handlers.

Scope

  • Decide the intended contract: is DeadlineExceeded always client-driven here, or should a server-side timeout log and (on API paths) return 500?
  • If the latter, split the classification so only Canceled is silenced, consistently across the sites above.
  • Document the decision where the pattern is defined.

Out of scope

  • The !824 (merged) repository handlers, which follow the existing convention on purpose.