-
-
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
fix(utils): Try-catch monkeypatching to handle frozen objects/functions #9031
Conversation
const proto = original.prototype || {}; | ||
wrapped.prototype = original.prototype = proto; | ||
addNonEnumerableProperty(wrapped, '__sentry_original__', original); | ||
} catch (o_O) {} // eslint-disable-line no-empty |
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.
h: I would add a log here (maybe even non-debug!). I can already see myself debugging an issue that some instrumentation isn't working. This is a very opaque way to fail.
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 can add a debug log, but wouldn't do a log. Because it is really not a user problem, the linked issue:
function callback() {
console.log("Hello");
}
setTimeout(callback, 50); // OK
Object.freeze(callback);
setTimeout(callback, 50); // BOOM!
Is generally totally OK to write but would result in this. the user shouldn't see a log because of this IMHO.
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.
Debug log sounds good!
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 added a debug log & integration tests to actually make sure the issue raised is fixed. Interestingly, if the function if frozen the actual monkey patching still works, only the setting of the wrapped property fails. So the error is still captured even if the callback is frozen, which is good I guess.
size-limit report 📦
|
89115ab
to
ca34264
Compare
231207f
to
b37c594
Compare
…ns (#9031) This try-catches any monkeypatching we do on objects, to avoid us throwing e.g. if trying to patch a frozen object. Obv. the monkey patching will _not_ actually work then, but I guess it's better to not wrap stuff than to error out in userland. I also added some tests for this! Fixes #9030
This try-catches any monkeypatching we do on objects, to avoid us throwing e.g. if trying to patch a frozen object.
Obv. the monkey patching will not actually work then, but I guess it's better to not wrap stuff than to error out in userland. I also added some tests for this!
Fixes #9030