sentry-javascript
sentry-javascript copied to clipboard
getsentry
'Object.setPrototypeOf' is not a function
Is there an existing issue for this?
- [X] I have checked for existing issues https://github.com/getsentry/sentry-javascript/issues
- [X] I have reviewed the documentation https://docs.sentry.io/
- [X] 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/browser
SDK Version
7.11
Framework Version
No response
Link to Sentry event
https://sentry.io/organizations/distrokid/issues/3336842991/?project=1394220&query=is%3Aunresolved+%21message%3AFloodControl&sort=freq&statsPeriod=24h
Steps to Reproduce
not sure, just getting a lot of errors via the js sdk
Expected Result
the sentry library shouldn't be generating logging errors itself? So far I've seen 20k
Actual Result
/7.1.1/bundle.es5.min.js: in Error thrown at line 2, column 5964 in n(n) in
/7.1.1/bundle.es5.min.js: in called from line 2, column 76862 in
Hi @zspitzer and thanks for reporting! This sounds interesting (haven't yet seen a similar error or reports). Would you mind sharing your Sentry setup? For example your Sentry.init, options and - if you have any - custom/advanced modifications (e.g. custom transport, etc). Also, it would be great if you could provide a minimal reproduction example that shows the bug. Thanks!
This is because of https://github.com/getsentry/sentry-javascript/pull/5087 - it seems we don’t include this polyfill for the es5 bundle for some reason. Cc @lobsterkatie
it seems we don’t include this polyfill for the es5 bundle for some reason
Yeah, I'll admit that for the sake of expediency I explained it in that PR description as an ES6 change, but the truth is I pulled it from all bundles because a) according to the MDN compatibility chart, the last browser to add support for it (Safari) did so in mid-2015 (seven years ago), b) our polyfill was only added because three years ago someone wanted to support the browser in Android 4 (released in 2011, eleven years ago), and c) I checked and I could have sworn that we already use the real one elsewhere, to no ill effect (though now that I'm checking again I can't find it anywhere, so either I was making that part up or it ended up getting cut out in all of our v7 refactoring).
I took a look at the linked issues and unfortunately they don't have any information about what browser they come from. One interesting thing: all of the ones which are tagged with an IP address come from a small group of IPs in Amsterdam. No idea if that's significant or not.
I'm willing to put the polyfill back if we decide it's worth the bundle size hit, but given the tiny sliver of end-users this is presumably coming from, I'd rather just add this to our defaults in ignoreErrors. @AbhiPrasad @Lms24 - thoughts?
P.S., @zspitzer - if the 23K is straining your quota, feel free to write into support, tell them Katie sent you (you can reference this comment), and they can gift you back enough events to cover the difference.
@lobsterkatie Thanks! quota isn't an issue for us, it's more spam/noise than anything else. this is all basically noise from bots I believe.
It's hard to repo as the linked issue and other entries I have found have mostly zero context beyond the sentry stack
@Lms24 Our Sentry init, is pretty basic, we just add a path to the entry title to provide context
Sentry.onLoad(function() {
Sentry.init({
environment: "PROD",
beforeSend: function(event, hint) {
const error = hint.originalException;
if (error && error.message && event.exception && event.exception.values
&& event.exception.values[0] && event.exception.values[0].value) {
var original_message = error.message;
event.exception.values[0].value = original_message + " (" + document.location.pathname + ")";
}
return event;
}
});
});
I'm willing to put the polyfill back if we decide it's worth the bundle size hit, but given the tiny sliver of end-users this is presumably coming from, I'd rather just add this to our defaults in ignoreErrors.
I think adding this to the ignoreErrors list is probably the better way to go (considering bundle size vs. value). Seems like these errors only produce noise and add little to no value.
Decided Relay was a better place for this - saves us needing to add the string to our bundle.
@zspitzer - Once the PR linked above is released, you'll be able to go to your project settings and turn on the browser extensions filter here:
(I know this isn't technically an extension causing the problem, but it's the closest match to what we need.)
Unfortunately, we just missed a Relay release, and they only happen once a month. So in the meantime, I'd suggest either adding this error message to ignoreErrors or adding a check in your beforeSend which returns null if it sees this error message. (They're functionally equivalent, so pick your favorite).
For SAAS Sentry relay should deploy immediately - the monthly releases are just for self-hosted.
Oh, that makes sense. I was generalizing from Anton's serverless work, but I suppose that's also self-hosted, in a way. Well, great, then. Much shorter waiting time!