Expand SpanStatus with NETWORK_CONNECTION_ERROR status

[Angelodaniel]

Problem Statement

about network connection errors: currently we can’t distinct them because there is no proper SpanStatus for that(Github).

Would it make sense to add that?

Solution Brainstorm

No response

[lcian]

As you can see from the code you linked and also from the develop docs the span statuses are intended to map to HTTP status codes.

In HTTP client integrations it looks like we generally (ab)use SpanStatus.INTERNAL_ERROR to surface network errors:

sentry-java/sentry-okhttp/src/main/java/io/sentry/okhttp/SentryOkHttpEventListener.kt

Line 212 in d372486

okHttpEvent.onEventFinish(CONNECT_EVENT) {

sentry-java/sentry-apollo-3/src/test/java/io/sentry/apollo3/SentryApollo3InterceptorWithVariablesTest.kt

Line 111 in d372486

fun `creates a span around the request failing with network error`() {

We can discuss it with the team but I think this is unlikely to be added, we would need to change the spec.

[lcian]

In general we should also capture an exception in HTTP client integrations when the request fails, which would include network failures.
Is there a particular case you noticed where we don't do this? @Angelodaniel

[adinauer]

We just had a quick chat about this and in the future we're planning to move to fewer possible span status values (just OK and ERROR) to align more closely to what OpenTelemetry does.

So it doesn't make much sense to add to SpanStatus now if it'll be replaced in the not so distant future.

Found https://getsentry.github.io/sentry-conventions/generated/attributes/error.html which we can probably use in the future to transport a reason for errors.

[zhukic]

Hi!

It's me who initially raised this question. We're developing a mobile application, and recently we started measuring the performance of our network requests, where each request is represented as a single transaction, and we noticed while all 3xx, 4xx, 5xx rates are 0%, the general failure rate of requests is about 5% due to rather not HTTP errors, but connection related errors(subtypes of IOException like connect/read/write timeouts, connection absence, etc.). When such an exception occurs, we map it to SpanStatus.INTERNAL_ERROR, which has 500 code under the hood.

The problem is that we can't distinguish such connection exceptions from HTTP errors because there is no corresponding span status for them. Also, setting an exception to the transaction also doesn't work because Sentry SDK doesn't send it(see discussion).

As the number of such errors is significant, we would like to have some way to distinguish them, but currently I haven't found a way to do that.

In addition, to correctly see network requests on the Network Requests page, we need to enrich transactions with the http.client span that should contain a response code. So, having HTTP codes in SpanStatus seems redundant.

To sum up everything mentioned above:

• We can't distinguish network connection errors from HTTP errors;
• There is no SpanStatus related to network connection errors.

@adinauer I'd appreciate your feedback about that.

Thank you!

[adinauer]

Thanks for writing in @zhukic. Asking internally whether there's a workaround until the new API is in place that doesn't require SDK changes.

[adinauer]

@zhukic can you query what you need when you add a value to transaction.data?

Should work like this: transaction.setData("error.type", "network_connection_error");

Doing this should also be forward compatible with the new API.

You may also find https://docs.sentry.io/product/explore/trace-explorer/ helpful.