Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

http.status_code tag in the transaction payload #445

Open
marandaneto opened this issue Oct 5, 2021 · 12 comments
Open

http.status_code tag in the transaction payload #445

marandaneto opened this issue Oct 5, 2021 · 12 comments

Comments

@marandaneto
Copy link
Contributor

unknown

The UI special case the http.status_code tag in the transaction payload (not spans) to show the status sublabel with the HTTP status code (see flask image).

This looks suboptimal due to, let's say we have a transaction that finishes with the status OK, this transaction has 2 spans which are HTTP requests, one of them is a 200 and the other one is a 500, both are running in parallel and since the tag is in the transaction tags and not span tags, the span that finishes the later always wins setting the tag, overwriting the previous tag.

The same transaction may have a 200 or 500 randomly and can be confusing.

is it an issue? should we address that? also, http.status_code isn't part of the spec so most SDKs are not setting it.

@rhcarvalho
Copy link
Contributor

For web servers, on the transaction level, the HTTP status is the status of the incoming request -- and not of any outgoing requests (child spans).

Does that clarify the case you are describing?

@marandaneto
Copy link
Contributor Author

@rhcarvalho mmmm, that makes sense, since each incoming request will be its own transaction.

should we doc this special tag @rhcarvalho ?

@rhcarvalho
Copy link
Contributor

should we doc this special tag @rhcarvalho ?

Yes, let's document it, it is used in the Sentry frontend and more SDKs could report it.

And apparently that expectation holds for more than two years, even before GA.

@marandaneto
Copy link
Contributor Author

we only document the HTTP client integrations https://develop.sentry.dev/sdk/features/#http-client-integrations but not Web servers, or is it documented somewhere else?

it should not be that different from the client one tho.

@marandaneto
Copy link
Contributor Author

Nope, this is not the same thing, this issue is about transactions and not events.

@romtsn
Copy link
Member

romtsn commented Nov 2, 2022

Whoever updates the spec, please share this with client-infra to make sure we're aligned between SDKs

@marandaneto
Copy link
Contributor Author

Cocoa also sends this tag for spans at least, I believe it might be related to https://github.com/getsentry/sentry-cocoa/blob/1453a8aaf8141ad4c304e723f1f17a674e2a839f/Sources/Sentry/SentryNetworkTracker.m#L250-L251

@adinauer
Copy link
Member

adinauer commented Aug 7, 2023

For Spring WebMVC we're currently unable to get the correct response code. For Spring WebFlux we've added the response code to contexts/response/status_code for transactions in getsentry/sentry-java#2870.

We have to check if the UI has already been updated to also look at http.response.status_code in Span data and contexts/response/status_code for transactions.

@adinauer
Copy link
Member

adinauer commented Aug 7, 2023

Just confirmed, UI does not look at contexts/response/status_code.

@adinauer
Copy link
Member

adinauer commented Aug 7, 2023

Also not http.response.status_code in Span data

@adinauer
Copy link
Member

adinauer commented Aug 7, 2023

We do not want to look at span data here as the status is supposed to display the status of the transaction.

Opened getsentry/sentry#54274 for reading the status code from response context in the UI.

Once the UI can show status code from there we can do start changing SDKs.

  • We also have to document where to put the status code for transactions.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants