I started hacking on IRC scripts in the late nineties and have been hacking on computers (and businesses) ever since. I love to build, learn, and share.
In the past I’ve disabled production gems in development entirely, and ran into similar issues. That’s the main reason in “development mode” the honeybadger gem behaves as close to production as possible—it executes all code paths up to notifying the server (which it mocks). That was a super intentional decision; you don’t want code running in production that isn’t running in development/test. I also recommend testing exception reporting in your test suite for similar reasons. docs.honeybadger.io/lib/ruby/getti...
Unfortunately that doesn’t usually cover production states which result from heavy load or server interactions, so having a production-like dev environment for that could be a nice extra precaution. It’s still not guaranteed to find issues like this before they happen, but it could help with quicker debugging/troubleshooting.
Load testing in general is also a good idea, and may help surface some issues faster. I like the idea of your StandardErrorWorker, Molly. Putting your application into exceptional states (and other failed states) under load could be a useful practice to help spot issues across the entire monitoring stack. Maybe I’ll try adding that worker to our own Rails app. ;)
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Right?! Honeybadger has filters and ways to ignore tags and projects so its kinda like why not?!
In the past I’ve disabled production gems in development entirely, and ran into similar issues. That’s the main reason in “development mode” the honeybadger gem behaves as close to production as possible—it executes all code paths up to notifying the server (which it mocks). That was a super intentional decision; you don’t want code running in production that isn’t running in development/test. I also recommend testing exception reporting in your test suite for similar reasons. docs.honeybadger.io/lib/ruby/getti...
Unfortunately that doesn’t usually cover production states which result from heavy load or server interactions, so having a production-like dev environment for that could be a nice extra precaution. It’s still not guaranteed to find issues like this before they happen, but it could help with quicker debugging/troubleshooting.
Load testing in general is also a good idea, and may help surface some issues faster. I like the idea of your StandardErrorWorker, Molly. Putting your application into exceptional states (and other failed states) under load could be a useful practice to help spot issues across the entire monitoring stack. Maybe I’ll try adding that worker to our own Rails app. ;)