otelhttp: client-initiated request termination is recorded as a 500 with span status Error

[danielloader]

When a client disconnects mid-request, the server handler observes the cancelled request context and typically returns an error, which our handlers surface as a 500. otelhttp then records http.response.status_code=500 and sets the span status to Error, because serveHTTP reads the status from RespWriterWrapper (which defaults to 200 and only records what the handler wrote) and never inspects r.Context().Err().

No response reached the client, so per the HTTP semantic conventions http.response.status_code should arguably be absent, since it is required only if a status was received or sent, and error.type should carry a low cardinality identifier instead. The client side already does this in transport.go via semconv.ErrorType, but the server path never sets error.type at all. Is the current server behaviour intentional, and would a check on the request context after next.ServeHTTP to distinguish a client disconnect from a genuine 500 be in scope?

[github-actions]

Pinging code owners for instrumentation: otelhttp: of approvers for this repository.

[MrAlias]

Thanks for the report. I reproduced this on current main with a real HTTP/1.1 disconnect: the handler waited for r.Context().Done(), then called WriteHeader(500). The ended server span had status Error and http.response.status_code=500, but no error.type.

Triage: confirmed bug, with a narrower fix than removing the status code.

• The missing error.type is a real semantic-convention gap. The server path currently ignores request-context cancellation, request-body read errors, and response write errors when classifying the operation. It also omits error.type for ordinary 5xx server responses. The HTTP conventions require error.type when a request ends with an error and say an incomplete send/receive should set span status to Error.
• The recorded 500 and Error status are consistent with the behavior exposed by the handler. http.ResponseWriter.WriteHeader provides no delivery acknowledgement, so otelhttp cannot know whether that status reached the peer. A cancelled request context alone should not erase a status the handler selected. The semantic-convention dropped-connection example likewise retains http.response.status_code while adding the disconnect's error.type.

This issue can track adding server-side failure classification to spans and metrics. A fix should:

1. Prefer an observed response write error, request-body read error, or request-context error as the failure cause.
2. Set span status to Error and add a predictable, low-cardinality error.type for that cause.
3. Preserve an observed/selected HTTP status code; for an error status without a more specific failure, use the status-code string as error.type.
4. Include a real disconnect regression test so cancellation is detected before the outer ServeHTTP returns.

The relevant requirements are in the HTTP span conventions and HTTP metric conventions.

[DuttaNeel07]

Hey @MrAlias !, I have read and understood the issue and would like to contribute the fix, can you assign this issue to me.

[danielloader]

Not to broaden it too much since I'm glad it's being looked at but I'm sure this is going to impact otelgin, otelmux and otelecho too - worth doing them all in one batch if it's a behavioural change I'd imagine to simplify the the release notes.

[MrAlias]

@danielloader if you can confirm this affects those packages as well, please open issues to track that work. We should not try to bloat the fix PR across all mentioned packages.

[danielloader]

Absolutely, will do.

Confirmed on main at 5f30960; all reproduced with a real HTTP/1.1 disconnect (handler blocks on the request context, then writes 500; client cancels mid-request), each recording http.response.status_code=500 with span status Error and no error.type:

• otelgin — otelgin: client-initiated request termination is recorded as a 500 with span status Error and no error.type #9374
• otelmux — otelmux: client-initiated request termination is recorded as a 500 with span status Error and no error.type #9375
• otelecho — otelecho: client-initiated request termination is recorded as a 500 with span status Error and no error.type #9376
• otelrestful — otelrestful: client-initiated request termination is recorded as a 500 with span status Error and no error.type #9377

otelrestful wasn't in my original list but is affected for the same reason, so I've included it for completeness — easy to close if it's out of scope.

Two things that came out of checking:

• All four vendor a byte-identical generated copy of internal/shared/semconv/server.go.tmpl, so the error.type classification itself is shared with otelhttp, but each middleware needs its own wiring to detect and pass the failure cause. otelmux already collects ReadError/WriteError from its wrappers and passes them to ResponseTraceAttrs, where they're currently discarded.
• otelecho records err.Error() as a free-text echo.error span attribute and never sets error.type. Since idiomatic Echo handlers return the error rather than writing a status, that's the common path — noted in otelecho: client-initiated request termination is recorded as a 500 with span status Error and no error.type #9376.