A request that takes longer than eight seconds gets no answer, because the server's write timeout runs out before the request timeout #208

New Issue

2026-10-09T16:03:03Z

cgalo5758 commented

2026-10-09 16:03:03 +00:00

What happens

Start in internal/server/server.go builds the http.Server with WriteTimeout: 8 * time.Second and puts every request through middleware.Timeout(32*time.Second). Go sets the connection's write deadline eight seconds after it reads the request's headers. The request timeout is http.TimeoutHandler. It holds the handler's response in a buffer and writes it only when the handler returns, or it writes its own 503 "Request timed out" at 32 seconds.

So when a handler runs past eight seconds, its work still finishes, but writing its answer fails and the server closes the connection. The person waits the whole time and gets no response from the console. Instead, the proxy in front shows its own gateway error, or the browser reports a dropped connection. The 503 that the request timeout writes at 32 seconds runs into the same expired deadline, so it never reaches anyone either. Nothing stops the handler at eight seconds: it keeps running until it returns, and its context is cancelled only at 32 seconds.

Two kinds of handler can run past eight seconds today:

A plan switch, cancel or keep makes several Stripe calls in a row (internal/fulfillment/plan_change.go). Each call uses the Stripe library's defaults: an 80-second timeout and two retries. When Stripe is slow, the change can go through while the member sees an error.
FedWiki's site actions start their workflow in the request, with a 10-second budget (workflowStartTimeout in internal/integrations/fedwiki/web/requests.go). When Temporal is slow, the console records the request and starts the workflow, but the member never gets the answer.

Timeout's doc comment says the client gets a 503 once the deadline passes, and openspec/specs/http-security-headers/spec.md requires that 503 to carry the security headers. The test of that 503 in internal/middleware/tests/security_headers_test.go writes to a recorder that has no write deadline, so it passes.

What should happen

The request timeout fires before the write timeout. A request that runs too long gets the 503 "Request timed out" with the security headers, and the write timeout only catches a client that is too slow to read the answer. Either the request timeout comes down below eight seconds, or the write timeout goes above 32 with room left to write the 503.

Where

internal/server/server.go (Start: the http.Server and preAuthStack); internal/middleware/timeout.go (Timeout).

Steps

Add time.Sleep(9 * time.Second) to any handler, run the console, and request that path directly with curl -v. After nine seconds curl reports "Empty reply from server". With a 40-second sleep you get the same empty reply at 32 seconds, which is when the 503 should arrive.

Why it matters

When Stripe, Temporal or the database slows a request past eight seconds, the console sends no answer at all, even if the work was done, and its "Request timed out" response is never seen.

## What happens `Start` in `internal/server/server.go` builds the `http.Server` with `WriteTimeout: 8 * time.Second` and puts every request through `middleware.Timeout(32*time.Second)`. Go sets the connection's write deadline eight seconds after it reads the request's headers. The request timeout is `http.TimeoutHandler`. It holds the handler's response in a buffer and writes it only when the handler returns, or it writes its own 503 "Request timed out" at 32 seconds. So when a handler runs past eight seconds, its work still finishes, but writing its answer fails and the server closes the connection. The person waits the whole time and gets no response from the console. Instead, the proxy in front shows its own gateway error, or the browser reports a dropped connection. The 503 that the request timeout writes at 32 seconds runs into the same expired deadline, so it never reaches anyone either. Nothing stops the handler at eight seconds: it keeps running until it returns, and its context is cancelled only at 32 seconds. Two kinds of handler can run past eight seconds today: - A plan switch, cancel or keep makes several Stripe calls in a row (`internal/fulfillment/plan_change.go`). Each call uses the Stripe library's defaults: an 80-second timeout and two retries. When Stripe is slow, the change can go through while the member sees an error. - FedWiki's site actions start their workflow in the request, with a 10-second budget (`workflowStartTimeout` in `internal/integrations/fedwiki/web/requests.go`). When Temporal is slow, the console records the request and starts the workflow, but the member never gets the answer. `Timeout`'s doc comment says the client gets a 503 once the deadline passes, and `openspec/specs/http-security-headers/spec.md` requires that 503 to carry the security headers. The test of that 503 in `internal/middleware/tests/security_headers_test.go` writes to a recorder that has no write deadline, so it passes. ## What should happen The request timeout fires before the write timeout. A request that runs too long gets the 503 "Request timed out" with the security headers, and the write timeout only catches a client that is too slow to read the answer. Either the request timeout comes down below eight seconds, or the write timeout goes above 32 with room left to write the 503. ## Where `internal/server/server.go` (`Start`: the `http.Server` and `preAuthStack`); `internal/middleware/timeout.go` (`Timeout`). ## Steps Add `time.Sleep(9 * time.Second)` to any handler, run the console, and request that path directly with `curl -v`. After nine seconds curl reports "Empty reply from server". With a 40-second sleep you get the same empty reply at 32 seconds, which is when the 503 should arrive. ## Why it matters When Stripe, Temporal or the database slows a request past eight seconds, the console sends no answer at all, even if the work was done, and its "Request timed out" response is never seen.

cgalo5758 added the

kind

bug

area/ops labels 2026-10-09 16:03:03 +00:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: wiki-cafe/member-console#208