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
ref(angular): Set Angular ErrorHandler specific Exception Mechanism #3844
Conversation
size-limit report
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The implementation is valid, so +1 on this. However, I think we should decide how to make a clear distinctions between handled/unhandled and mechanisms name. If we decide to go with this PR, then we should also update Vue, Ember, React and all remaining frameworks to with the correct mechanism name.
cc @getsentry/team-webplatform
I've been wanting to circle back around to mechanism for a while. I definitely think there are ways we could be clearer about what's what. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@AbhiPrasad pointed me here when we were talking about hints.
Hints work, but are a form of two-way communication between the SDK and user code that we sometimes abuse to pass information around. In particular, I find this use of hint.data
harder to understand and maintain than alternatives.
One alternative, what SDKs like angular, ember, etc can do is to use a Scope-based Event Processor to mutate the event in arbitrary ways, without requiring extra code in upstream packages like @sentry/browser
(so probably a win in terms of bundle size).
These changes lgtm, can we merge it? |
This pull request 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 🥀 |
@onurtemizkan could you please update this branch and lets merge? This resolve an issue I opened (#3836) and seems to have all approvals it needs |
I would like to see us switch to using a scope processor vs. adding the mechanism through a hint. |
573feac
to
039919d
Compare
size-limit report 📦
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@onurtemizkan is there any chance we could add a test for this change? I recently started adding tests for the changes I made to the Angular SDK and I think it should be possible to add a simple test for this.
I know that our testing setup is far from optimal for Angular rn but it's on my todo list to change that.
If it turns out that it's not that easy then that's fine as well. We can come back to it once I improved our setup.
EDIT: fyi, in #5416 I'm adding a few more tests.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One more remark @onurtemizkan, thanks!
packages/angular/src/errorhandler.ts
Outdated
getCurrentHub().captureException(extractedError, { data: { mechanism: { type: 'angular', handled: false } } }), | ||
); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we change the way of passing on the mechanism to using an eventprocessor on the scope? Similarly to how we do it in remix here? If this is possible, we'd prefer that over adding it to the hint.
- Provide 'angular' as the mechanism for handled angular errors.
039919d
to
5d94e2a
Compare
Thanks for the review @Lms24! Updated the PR |
packages/browser/src/eventbuilder.ts
Outdated
const providedMechanism: Mechanism | undefined = | ||
hint && hint.data && (hint.data as { mechanism: Mechanism }).mechanism; | ||
const mechanism: Mechanism = providedMechanism || { | ||
handled: true, | ||
type: 'generic', | ||
}; | ||
|
||
addExceptionMechanism(event, mechanism); | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Now that we're using the scope eventprocessor - do we still need this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The default fallback mechanism seems unneeded at this point, removing it.
Not sure about the rest, though.
The original intent on this PR was to mimic how mechanisms are passed in Node SDK on browser SDK, but a lot changed since, so I don't know if that's still relevant.
Still, it looks like this can also be moved into scope.addEventProcessor
to be consistent, if we are keeping it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it's better to change the Node approach to how we do it in Express (and Angular). (But let's do this in another PR). Which makes me think that we don't need to query the hint here. The original call to addExceptionMechanism
shouldn't be a problem because it won't overwrite the already set mechanism with the default value (see here)
So overall, I don't think we need this change here (unless I'm missing something)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for adding the tests and the scope event processor @onurtemizkan
The linter isn't happy yet but I think that's easily fixable.
Just one more question (above) and then I think this is ready to go.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @onurtemizkan ❤️
angular
exception mechanism.
Fixes: #3836
(Edited by @Lms24 because the PR changed quite a bit)
Previously, exceptions caught in the Sentry Angular
ErrorHandler
defaulted to the generic mechanism, meaning they were marked ashandled: true
andmechanism: generic
. This PR adds a custom mechanism for these events:handled: false
(because they were caught in our ErrorHandler) andmechanism: angular
.The mechanism is set by using a Scope Eventprocessor (similarly to how we do it in the Remix SDK)