Skip to content
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

Provide hook to add metadata #142

Closed
padolsey opened this issue Oct 16, 2013 · 8 comments
Closed

Provide hook to add metadata #142

padolsey opened this issue Oct 16, 2013 · 8 comments

Comments

@padolsey
Copy link

It would be really nice if raven-js provided a mechanism for devs to add their own metadata (i.e. via the extra option). Right now, in order to do this, I have to take charge of catching my app's errors myself and then manually calling captureException:

Raven.captureException(error, { extra: { /* metadata*/ } });

I would prefer a way where I can still take advantage of Raven's default window.onerror handling. Maybe there is one that I'm not aware of?

So I guess the question becomes: Is there a way to add extra data to every sent exception without having to catch the exceptions myself?

@mattrobenolt
Copy link
Contributor

Well, you really shouldn't be using the fallback window.onerror anyways. That's a last ditch effort.

Raven explicitly monkey patches things so that it can be done with Raven.captureError.

Today, if you use Raven.context or Raven.wrap, you're able to pass along your own extras. See: http://raven-js.readthedocs.org/en/latest/usage/index.html#passing-additional-data

I can add a callback for Raven.onException or something that you can register to patch on more stuff at a global context though.

@padolsey
Copy link
Author

Thank you for the quick response!

You're right -- we shouldn't really be using window.onerror -- but there seem to be some exceptions that are otherwise very tricky to catch because of their async nature (although am working at "hooking" into these areas).

A Raven.onException would be incredibly useful I think -- it'd enable people to add metadata at the time of exception too, which I don't think is possible with context/wrap (with them, you have to prepare the metadata beforehand).

@mattrobenolt
Copy link
Contributor

Yes, you would have to prepare the data beforehand. What is your usecase where you'd want to prepare on the fly? Just curious so I can construct a callback that makes sense.

@padolsey
Copy link
Author

I should have mentioned that before, sorry.

I want to send, along with the exception, details of the DOM events leading up to the exception. I have a function which intercepts dispatched jQuery events, logs them (throwing them away after 5000ms). If an exception occurs within 5000ms of the DOM event I will send info about that dom event within the extra data. Stack traces on minified sources don't give enough info to determine where the problem is (e.g. error @ line 1, which contains 10000 characters) -- so I was thinking of sending some additional info along, and "dom events leading to an error" seemed like the wisest choice at the time. (interested if you have any thoughts about this)

This reminds me of another issue (#58). If my payload, including the dom-event stuff, is too big will it just error out?

@mattrobenolt
Copy link
Contributor

Why was this closed?

To address your question, yeah, there is a limit to how much data you can send along with an error. But that limit has to do with your Sentry server (or getsentry.com). Very specific to configuring nginx or whatever you're using. Older browsers also have limits for the length of a url.

And yeah, it'll silently fail if it's too long, unfortunately. If you configure your nginx to accept a really long uri and the target is modern browsers, you can make it work though. getsentry.com has a pretty large limit.

@padolsey
Copy link
Author

Sorry for closing -- was about to add an explanation -- realised that the dom-event thing is moot (or should be) if we use source maps.

@padolsey
Copy link
Author

Thank you for the info regarding the payload length.

@mattrobenolt
Copy link
Contributor

Ah yes, source maps are basically essential IMO. Let me know if you have any issues with that too. :)

kamilogorek pushed a commit that referenced this issue Jun 12, 2018
mydea added a commit that referenced this issue Jan 5, 2024
- fix(rrweb): Use unpatched requestAnimationFrame when possible [#150](getsentry/rrweb#150)
- ref: Avoid async in canvas (#143)
- feat: Bundle canvas worker manually (#144)
- build: Build for ES2020 (#142)
mydea added a commit that referenced this issue Jan 8, 2024
- fix(rrweb): Use unpatched requestAnimationFrame when possible [#150](getsentry/rrweb#150)
- ref: Avoid async in canvas (#143)
- feat: Bundle canvas worker manually (#144)
- build: Build for ES2020 (#142)
mydea added a commit that referenced this issue Jan 10, 2024
This bump contains the following changes:

- fix(rrweb): Use unpatched requestAnimationFrame when possible
[#150](getsentry/rrweb#150)
- ref: Avoid async in canvas
[#143](getsentry/rrweb#143)
- feat: Bundle canvas worker manually
[#144](getsentry/rrweb#144)
- build: Build for ES2020
[#142](getsentry/rrweb#142)

Extracted out from
#9826

Closes #6946
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants