-
-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
node http integration: ignoreIncomingRequests() option does not work #12913
Comments
After some digging I found that the issue was introduced in this PR: #10443 As a result, when we call getRequestUrl(request):
which expects a RequestOptions object:
all of the params it tries to access are undefined: sentry-javascript/packages/node/src/utils/getRequestUrl.ts Lines 4 to 15 in eaf6055
leading to the method returning |
One option: can we return the full request object back to the user in the ignoreIncomingRequests() user supplied hook? |
Alternatively: is it acceptable to pass just I don't see anywhere to get the extra bits of protocol, hostname, etc. in the IncomingMessage type. |
Hey @Bruno-DaSilva thanks for writing in and for the excellent detective work! I'll take a look at this today and respond to your suggestions a bit later. |
I can confirm that currently, To fix this, I think the best option is to take If this is enough, we're good. Otherwise, we can still let users overwrite the Otel's |
Hey @Lms24 thanks for jumping on this so quickly :)
yup that sounds reasonable to me.
May be worth a deeper look. Seems it'd be prone to future mistakes in general if we're somehow disabling type checks inadvertently here. I don't have the sdk setup locally to run any typescript builds atm.
I was unsure if this is possible here. Are you referring to passing in the experimentalConfig?
The issue with that is the I'll admit I haven't tried it so instead i'm relying on a patch-package config instead. If the above is true, do we want to move _experimentalConfig below the sentry-defined parameters so they can act as overrides? That could be a breaking change if people are adding some ineffective hooks lol (though I suppose the interface marks it as can-break-at-any-time) |
you're totally right. I also noticed that |
Hey, yes it is on purpose that we override this, we do not allow to override this because we depend on our custom functionality. The idea was that it should be enough to look at the URL we pass into the proper options we have, if that is incorrect we def. should fix this! Also we could think about adding the request as a second argument to the callback, I guess, this should be non-breaking I believe? Would be an escape hatch at least! |
that's a good idea! I opened #12929 to fix the |
I like this idea; you get the full benefit creating your own hook (access to the request arg and influence on the return) without totally overriding the sentry one. Then the sentry built-in function becomes more of a wrapper/middleware around the user's custom function. I like that generally to allow power users as much extensibility as possible :) |
Hey, the initial fix for the Adding the second |
The second |
Wooo!!! thank you @Lms24 <3 |
Is there an existing issue for this?
How do you use Sentry?
Sentry Saas (sentry.io)
Which SDK are you using?
@sentry/node
SDK Version
8.17.0
Framework Version
No response
Link to Sentry event
No response
SDK Setup/Reproduction Example
Steps to Reproduce
Expected Result
all incoming http urls are a string matching the request, usable to filter ignore true/false
Actual Result
all incoming http urls are passed as '///' in the logs.
The text was updated successfully, but these errors were encountered: