Description
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
truncateworks 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