The behaviour you describe for the auto-instrumentation of Apache HttpClient is correct according to the OpenTelemetry specification for HTTP client and server spans. • For 4xx errors, the client span has error: true • For 5xx errors, both client and server spans have error: true See the spec https://opentelemetry.io/docs/specs/otel/trace/semantic_conventions/http/#status. The https://raw.githubusercontent.com/steffan-westcott/clj-otel/master/doc/images/honeycomb-trace.png on the clj-otel GitHub page shows Honeycomb correctly displaying a 4xx client span as an error. Note the HTTP GET span name and span extent in the waterfall diagram are shown in red.

The catch you describe has no impact on the client span because that span ends before the HTTP response is passed to your client-side code.

Ah yes, I should have phrased that better. I don't think it's an issue with the auto-instrumentation or with clj-otel. I'm just wondering whether there's anything that could be done to prevent that span from showing up as an error in honeycomb, in the scenario where the error is handled. Referring to the screenshot, the "2 spans with errors" bit is really useful to us for navigating large traces and jumping to the traces that have errors, but there's currently a lot of noise when we try to use that feature.