-
-
Notifications
You must be signed in to change notification settings - Fork 1.7k
fix(node): Skip capturing Hapi Boom error responses. #11151
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
Conversation
size-limit report 📦
|
762985d
to
9b45cec
Compare
9b45cec
to
c671e1f
Compare
Resolves: #11069 After checking the behaviour, it seems to me that we don't need to capture any Boom responses, as the errors that may cause a `5xx` response are already captured by the core logic. To add an option to control this behaviour, we need to update the usage of `hapiErrorPlugin`, converting it to a function signature, which IMO may not worth doing, as I'm not sure if users in general would need to use it. This also adds `expectError()` to the `node-integration-tests` runner to allow `5xx` responses to be tested.
Resolves: #11069 After checking the behaviour, it seems to me that we don't need to capture any Boom responses, as the errors that may cause a `5xx` response are already captured by the core logic. To add an option to control this behaviour, we need to update the usage of `hapiErrorPlugin`, converting it to a function signature, which IMO may not worth doing, as I'm not sure if users in general would need to use it. This also adds `expectError()` to the `node-integration-tests` runner to allow `5xx` responses to be tested.
Backport of #11151 to v7 Co-authored-by: Onur Temizkan <[email protected]>
Resolves: getsentry#11069 After checking the behaviour, it seems to me that we don't need to capture any Boom responses, as the errors that may cause a `5xx` response are already captured by the core logic. To add an option to control this behaviour, we need to update the usage of `hapiErrorPlugin`, converting it to a function signature, which IMO may not worth doing, as I'm not sure if users in general would need to use it. This also adds `expectError()` to the `node-integration-tests` runner to allow `5xx` responses to be tested.
This doesn't seem to be in the 8.7.0 release? |
This was released with |
I mean this particular fix. It looks like develop has not been merged to master since this was merged. Edit: I might just be confused about the project structure when looking at the downloaded source. I haven't actually reproduced. |
https://github.com/getsentry/sentry-javascript/commits/master/?author=onurtemizkan ![]() The commit shows up in the master branch you're right though that master is the source of truth for the releases, but master and develop are synced up. if you have a repro, thats best for us to take another look! |
Looks like updates in this commit did not apply when we moved this integration from |
ah good catch! does the same apply for v7? |
Thanks! |
@onurtemizkan thanks for catching this (and thank you @camsteffen for reporting!!) we'll get this in with the next release |
Recreating #11151 for v8 again, as the updates seem to be lost when moving the instrumentation inside the project structure. The testing updates introduced in the original PR do exist in develop / master, so this PR only reintroduces changes in the instrumentation code.
Resolves: #11069
After checking the behaviour, it seems to me that we don't need to capture any Boom responses, as the errors that may cause a
5xx
response are already captured by the core logic. To add an option to control this behaviour, we need to update the usage ofhapiErrorPlugin
, converting it to a function signature, which IMO may not worth doing, as I'm not sure if users in general would need to use it.This also adds
expectError()
to thenode-integration-tests
runner to allow5xx
responses to be tested.