Among the few people who have access to errorception right now, some of them are very high traffic sites. More traffic leads to more errors recorded, for obvious reasons. That's awesome because it's a great way to improve the site's UX. However, it had become a challenge to manage these large numbers of errors. It's only human nature that when there's a lot of noise you start missing the real signals. Something had to be done to manage errors better.
A quick look at other bug-reporting systems to see how they handle noise like this, and it's obvious that a "mark as duplicate" functionality was sorely needed in errorception. However, no one likes to be the guy marking bugs as duplicate. It requires review, testing, some familiarity with the code, and usually a lot of discussion around it. Not to mention that you need to remember that you had seen a similar bug filed before, find it, and cross-link them when marking as a dupe. Painful.
Errorception is in a unique position, though. Since errorception already knows a lot about the bug (errorception filed the bug report after all), it should be easy to reliably figure out which bugs are duplicates of each other, and mark them as such.
Yesterday, I rolled out an update that automatically marks duplicates of different errors. It's super simple to use - there's literally nothing you need to do! All old errors in the system, and new errors that will be logged are now all going to automatically mark themselves as duplicates of each other whenever appropriate.
The functionality is currently a little conservative, so the signals it uses doesn't work very well with inline scripts in dynamic pages. However, even with this conservative approach, the number of errors you need to worry about has come down by 55% on average, and as much as 75% in some cases! Less errors = happy developer. :)
Feedback welcome, as always.
A quick look at other bug-reporting systems to see how they handle noise like this, and it's obvious that a "mark as duplicate" functionality was sorely needed in errorception. However, no one likes to be the guy marking bugs as duplicate. It requires review, testing, some familiarity with the code, and usually a lot of discussion around it. Not to mention that you need to remember that you had seen a similar bug filed before, find it, and cross-link them when marking as a dupe. Painful.
Errorception is in a unique position, though. Since errorception already knows a lot about the bug (errorception filed the bug report after all), it should be easy to reliably figure out which bugs are duplicates of each other, and mark them as such.
Yesterday, I rolled out an update that automatically marks duplicates of different errors. It's super simple to use - there's literally nothing you need to do! All old errors in the system, and new errors that will be logged are now all going to automatically mark themselves as duplicates of each other whenever appropriate.
The functionality is currently a little conservative, so the signals it uses doesn't work very well with inline scripts in dynamic pages. However, even with this conservative approach, the number of errors you need to worry about has come down by 55% on average, and as much as 75% in some cases! Less errors = happy developer. :)
Feedback welcome, as always.
This brought down the error count for me.
ReplyDeleteI have this error that happens in our test environment through a page performance script as some older screen in the application dont have the right includes and blah blah.... I know I should fix it.
But here is the scenario - what if I want to tag a particular error type as IGNORE. There is a muted tab in errorception of which am not too clear. Is it the same?
Also, can I tag errors to types depending on page url. Since page url acts as the main context reference for an error, why cant I tag urls and use it to create error buckets. Lets say I have 5 urls for profile pages. I can tag these five urls with a tag 'Profile Errors'. All errors on these screens can get logged to this tag and come in a different list all together.
Also, I am posting the suggestion here as the feedback screen is not opening up in Chrome :P Dunno why.
Cheers!!!!
Thanks for the feedback, Moha. I wonder why the feedback page didn't work. It's a stock UserVoice page. Any details will be helpful.
ReplyDeleteAbout ignoring errors and the muted tab: You are right in that they are the same thing. However, there's currently no way to manually mute/ignore an error. All the muting happens automatically based on certain signals in the error. I'll be adding manual muting soon enough though. (This is the same for duplicates as well - only automatic, no manual currently, manual coming soon.)
I love the tagging idea. That's an awesome way to group errors. I'll keep it high on my priority list, and will let you know once I have something like it incorporated.
Thanks again for the feedback. Keep it coming!
The feedback page works today. It was an unable to connect to server issue. Not a 404 or anything similar. Might have been one odd case ;)
ReplyDelete