Mismatching trace information between issue details page and events details page

[lesliewu1]

Is there an existing issue for this?

• I have checked for existing issues https://github.com/getsentry/sentry-javascript/issues
• I have reviewed the documentation https://docs.sentry.io/
• I am using the latest SDK release https://github.com/getsentry/sentry-javascript/releases

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:

1. setup Sentry.captureException and sentry tracing for node
2. throw a handled error with a certain error code (lets say 403)
3. view the issue in Sentry, scroll to "Trace Details", notice that "Status" is "unknown" (not 403 / permission_denied)
4. Click into "Search by Trace" and notice that the correct trace is there, alongside the correct "Transaction Status" (permission_denied)
5. Click into "View Event", and see the correct Status, Code, and Trace Details on this page

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

1. We are seeing "unknown" in the "Status" field in this view

2. But then, clicking into "Search by Trace" shows the correct status code

3. 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).

[lforst]

Hi, thanks for writing in! Can you share what integrations/frameworks you're using and how you set up the SDK? Thanks!

[lesliewu1]

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:
Sentry.captureException(err, generateSentryUserContext(req.customFields));

[lforst]

@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)

[lesliewu1]

@lforst sorry - just updated my previous comment!

[lforst]

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.

[lesliewu1]

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:

1. When we explicitly send the response code BEFORE throwing an error (then default error handler is called and captures the exception to Sentry) --> we see that the correct status code is shown under Trace Details in the Issues view

2. When we explicitly send the response code within our default error handler and BEFORE calling the capture exception to Sentry --> we see that the status code is "unknown", but following trace details shows the correct code ( 409 / "already_exists" )

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.

[github-actions]

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 Status: Backlog or Status: In Progress, I will leave it alone ... forever!

---

"A weed is but an unloved flower." ― Ella Wheeler Wilcox 🥀