-
-
Notifications
You must be signed in to change notification settings - Fork 1.7k
Mismatching trace information between issue details page and events details page #6616
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
Comments
Hi, thanks for writing in! Can you share what integrations/frameworks you're using and how you set up the SDK? Thanks! |
Hey @lforst - for frameworks we use express/node.js/typescript and to setup the SDK we pretty much followed the setup guide step by step. Code is below: Then on exception, we call this: |
@lesliewu1 You shared a backend event in your issue. What backend framework are you using and how did you set up the SDK? (ideally you share the code) |
@lforst sorry - just updated my previous comment! |
Got it thank you! We should look into this and check if this is intended or an error. The reason I say this might be intended is because at the point in time the exception is captured (and potentially sent), we can't know what the response status code is yet therefore the status of the active trace/transaction/span is unknown. The trace details just displays what was captured in the error - it isn't really connected to the actual trace. |
Appreciate it! What you said definitely makes sense - additionally what we noticed though, was that when we tried to explicitly send the response status code before capturing the exception, sometimes it still would show up as "unknown". Here are two examples:
In both cases, we would expect to see the correct status code since the response is being sent before the exception is captured and sent to Sentry. |
This issue has gone three weeks without activity. In another week, I will close it. But! If you comment or otherwise update it, I will reset the clock, and if you label it "A weed is but an unloved flower." ― Ella Wheeler Wilcox 🥀 |
This issue has gone three weeks without activity. In another week, I will close it. But! If you comment or otherwise update it, I will reset the clock, and if you remove the label "A weed is but an unloved flower." ― Ella Wheeler Wilcox 🥀 |
It's unfortunate it was closed, I'm also quite confused about sentry's inability to determine transaction status. (Essentially making your 'failure rate' metric 0, no matter what) |
Is there any additional information we could provide? |
@nikitar Hi, since this issue is already super old and contains some API that is already outdated, would you mind opening a separate issue outlining your problems? Thanks. |
Is there an existing issue for this?
How do you use Sentry?
Sentry Saas (sentry.io)
Which package are you using?
@sentry/node
SDK Version
7.28.0
Framework Version
No response
Link to Sentry event
(https://sentry.io/organizations/vontive/issues/3798427835/?environment=prod&project=1297687&query=is%3Aunresolved&referrer=issue-stream)
Steps to Reproduce
We are using Sentry.captureException and sentry tracing to log errors in Sentry. We noticed that under "Issue Details" for a given error event, the trace information seems to be missing / mismatched - specifically, the "Status" field.
To repro:
Expected Result
We are expecting to see the "Trace Details" under the "Issue" view and "Event" view to be the same, especially given they share the same trace Id (specifically, we are expecting the same status code)
The details under "Issue", clicking into "Search by Trace", and clicking into "View Event" should match.
If they are not intended to match, my question would then be: what is the "Status" field under "Trace Details" in the Issue page view supposed to represent?
Actual Result
We are seeing "unknown" in the "Status" field in this view
But then, clicking into "Search by Trace" shows the correct status code
Then, clicking into "View Event" also shows the same and correct status code
I am looking for help understanding why 1 does not match with 2 and 3 - whether that is in the way we configure, or something else.
Additionally, it seems a bit odd that this is not a problem when the response code is 2XX like in this example. It only really happens when the response is an error code (4XX or 5XX).
The text was updated successfully, but these errors were encountered: