1) the suspense in reading this almost killed me š
2) Iāve been but my similar issues with Sentry and am starting to think enabling real error reporting in development might be a good idea all the time.
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.
Two thoughts...
1) the suspense in reading this almost killed me š
2) Iāve been but my similar issues with Sentry and am starting to think enabling real error reporting in development might be a good idea all the time.
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. ;)