Missing per-request timeout for Git LFS chunk transfers in Forgejo

Direct answer

As of Forgejo v1.22.x there is no LFS_TIMEOUT setting in app.ini and no merged pull request that adds one. The LFS chunk upload/download handlers in modules/lfs/server.go run on a plain net/http server and do not inherit the global SERVER_TIMEOUT or WEBHOOK_TIMEOUT values. Stalled client connections can therefore hold goroutines and file descriptors indefinitely.

Implementing a per-request timeout is technically feasible but requires wrapping the LFS handlers with a context.WithTimeout derived from a new config key and propagating that context through the underlying storage layer (local filesystem or S3). The Tus resumable‑upload protocol used by git-lfs and the GitHub CLI will retry a chunk if the connection is closed mid‑transfer, so a server‑side timeout that exceeds the typical chunk transfer time (default 1 MB chunks) is safe for clients.

Mirroring and background LFS sync jobs (PullMirrorLFS, scheduled pulls) use their own HTTP client timeouts (default 30 s) and are unaffected by an inbound LFS transfer timeout.

What would need to change

1. Add LFS.TIMEOUT (or similar) to app.ini.sample and the configuration loader.
2. In modules/lfs/server.go, wrap UploadHandler and DownloadHandler with a middleware that creates ctx, cancel := context.WithTimeout(r.Context(), cfg.LFS.Timeout) and passes ctx to the storage operations.
3. Ensure the Tus state machine treats context.Canceled / context.DeadlineExceeded as non‑fatal so the client can resume cleanly.
4. Add a cleanup routine for partial chunks left on disk when a write is cancelled.

Risks of an aggressive timeout

• Setting LFS_TIMEOUT below ~10 s will break uploads on high‑latency or bandwidth‑constrained links, causing repeated chunk retries and increased load.
• If the timeout fires after the storage write has started but before it finishes, a partial object may remain on disk until a garbage‑collection job removes it.

Current upstream status

Forgejo issue tracker shows open discussions requesting an LFS timeout, but no merged PR on the v1.22 release branch. The feature is therefore not on the immediate roadmap unless a contributor submits a PR with the changes outlined above.

Workaround today

If you need a bound right now, place a reverse proxy (nginx, Caddy, Traefik) in front of Forgejo and enforce proxy_read_timeout / proxy_send_timeout on the /lfs/ location. This kills stalled connections at the proxy layer without touching Forgejo code.

One diagnostic detail that would change the recommendation

Are you seeing OOM kills or file‑descriptor exhaustion on the Forgejo host during large LFS uploads, or is this a preventive hardening request? If the former, the proxy workaround is the fastest mitigation; if the latter, a config‑driven timeout can wait for a proper upstream implementation.