You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Recently I noticed our Typescript Vue app giving me Rollbar items with stacked errors featuring the same error trace:
Reaching out to support they informed me this is due to trace_chain being set in the payload, and is indicative that there are two errors, the first being the caught error and the second coming from error.cause.
This makes sense, our error classes do keep track of wrapped errors using cause, however I would expect to see two different stack traces, and in the examples I looked at, the trace was always duplicated.
Digging through the client, I can see support for this was added in #759 and #1012. But I believe there is an issue with this line:
For errors with causes, buildTrace is called in a loop, but each iteration continues to use the main stack trace from item. It's likely the line should be:
varstack=stackInfo.stack;
Since stackInfo is set to the current iteration.
More than happy to contribute a PR for this fix.
The text was updated successfully, but these errors were encountered:
Recently I noticed our Typescript Vue app giving me Rollbar items with stacked errors featuring the same error trace:
Reaching out to support they informed me this is due to
trace_chain
being set in the payload, and is indicative that there are two errors, the first being the caught error and the second coming fromerror.cause
.This makes sense, our error classes do keep track of wrapped errors using cause, however I would expect to see two different stack traces, and in the examples I looked at, the trace was always duplicated.
Digging through the client, I can see support for this was added in #759 and #1012. But I believe there is an issue with this line:
rollbar.js/src/browser/transforms.js
Line 233 in d8ea895
For errors with causes,
buildTrace
is called in a loop, but each iteration continues to use the main stack trace fromitem
. It's likely the line should be:Since
stackInfo
is set to the current iteration.More than happy to contribute a PR for this fix.
The text was updated successfully, but these errors were encountered: