Document in SDK `Expected Features` the HTTP integrations about develop HOT 12 CLOSED

@maciejwalkowiak after finishing the PR and docs, let's tackle this.

from develop.

We let it bubble up to global error handlers and handle it there.

from develop.

yep, thats what I've thought as the span is already finished.

@rhcarvalho what we do is to keep a WeakRef<Span, Exception> of the Exception, see the okhttp https://github.com/getsentry/sentry-java/blob/main/sentry-android-okhttp/src/main/java/io/sentry/android/okhttp/SentryOkHttpInterceptor.kt#L35
so if the event gets captured by the user or handlers, the event will contain the correct span info.

from develop.

Jus throwing an asterisk in here that once the dynamic sampling stuff goes live, anything about sentry-trace will also be about tracestate, and will therefore involve different methods (getTraceHeaders rather than toSentryTrace, for example). Nothing to do right now, just something to keep in the back of our collective minds.

from develop.

Should the SDK raise an event if a 5xx comes? If so what contexts.. If not, how does it propagate context upstream?

is missing but as soon as we get some feedback from the Dart integration that also captures events from failed requests, @ueman will include that too.

from develop.

@kamilogorek how does this work for XHR and fetch?

from develop.

What are you asking about exactly? We do capture breadcrumbs for these, as well as spans when tracing is enabled.

from develop.

@kamilogorek I guess its a general question about what do you do when instrumenting HTTP requests?

Start/Finish a span, also include sentry-trace header
Add a breadcrumb
Capture an error if any, do we collect metrics, etc

from develop.

@kamilogorek any input here? thanks

from develop.

Uh, sorry, you could ping me way earlier 🥲

For both, XHR and Fetch we:

• capture span (if tracing enabled - requires @sentry/tracing package)
• include sentry-trace (if tracing enabled - requires @sentry/tracing package)
• capture breadcrumbs (success status, response code, url, method - through integration, turned on by default)
• no additional metrics captured (eg. timings)

from develop.

@kamilogorek forgot about it too ^^

do you captureException(x) if the request throws for some reason? or you let the user to handle that

from develop.

We let it bubble up to global error handlers and handle it there.

@marandaneto One thing to pay attention here is what the user expectation is and what the product does. Right now we have a problem that Fetch errors end up linked to the transaction instead of the specific span. Ideally the specific span where an error happened should be the one providing the span context for the error event.

from develop.