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

maxMessageLength does not play well with angular plugin #605

Closed
jrencz opened this issue Jun 9, 2016 · 3 comments
Closed

maxMessageLength does not play well with angular plugin #605

jrencz opened this issue Jun 9, 2016 · 3 comments

Comments

@jrencz
Copy link
Contributor

jrencz commented Jun 9, 2016

TL;DR

If maxMessageLength is lower than angular error length the regex in raven angular plugin won't detect the error as angular error.

The story

I tried to enable angular plugin in my project (nonpublic). After enabling the plugin I intentionally introduced a repeater duplicate error into one of my templates (ngRepeat:dupes)
I expected the plugin to send transformed error to Sentry as it claims to do.
Instead it sent a generic error.
I logged out the error that was matched against. It was more or less this:

[ngRepeat:dupes] Duplicates in a repeater are not allowed. Use 'track by' expression to specify unique keys. Repeater: element in elements | orderBy: 'createdAt' track by element.id, Duplicate key: 25, Duplicate value: {"id": 25… 

Which was obviously the problem.
I found out that I'm using maxMessageLength in Raven.config().
This makes the analysed exception value not what the plugin expects to be.

After disabling the maxMessageLength it started matching angular errors fine.
This is because default maxMessageLength is 0 which is interpreted as "don't truncate"

Possible fixes

  • allow plugins to access raw, untruncated data
  • allow plugins to access and analyse config to warn which options may affect plugins' tasks
  • allow plugins to modify the way truncate works or disable it according to plugin logic.

The latter seems to be the most reasonable suggestion: angular errors are enormous and they should be truncated (this is why I set maxMessageLength in the first place) but they should be truncated in a meaningful way.

As I see it, it can be done with current architecture using "ignoreErrors" option but then plugin would have to turn the error into something else that won't be ignored next time and resend it. Or just stop truncating message in _processException if later _trimPacket which is called by _send does the job? This way data callbacks will probably get full message. But I'm not sure what would get broken. Can Anyone review this suggestion?


Raven version: 3.0.4

@benvinegar
Copy link
Contributor

allow plugins to access raw, untruncated data

I think we just move truncation to the end.

@jrencz
Copy link
Contributor Author

jrencz commented Jun 10, 2016

I think we just move truncation to the end.

If I'm not mistaken it's already there: https://github.com/getsentry/raven-js/blob/05671a8c9bb50ffad93deca3f677a6fee5d1a767/src/raven.js#L1205

Is there a reason why it's done twice (in _processException and in _trimPackage) now?

@benvinegar
Copy link
Contributor

Is there a reason why it's done twice (in _processException and in _trimPackage) now?

Not sure, maybe @mattrobenolt knows.

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