Clojurians Log v2
pedestal
Heya, I am looking at error-stylobate triggered errors. These felt a lot to me like our old broken pipe errors (which Pedestal now ignores by default). But this time I'm seeing Connection reset by peer errors.
To me, importance-wise, I think Connection reset by peer errors are as interesting as broken pipe errors. Would others agree?
At first I assumed broken pipe had been renamed by underlying tech to Connection reset by peer, but nope. They are distinct errors which I've managed to reproduce locally with a little test app (at least on Linux).
I noticed these Connection reset by peer errors because the cljdoc logger was trying to send them to http://sentry.io, and sentry was rejecting them because they were too big (some around 20mb and others around 50mb!, maybe cljdoc is loading a bit too much into the old context!).
I think I'm going to go ahead and adjust cljdoc to ignore Connection reset by peer.
If you think this also makes sense for Pedestal, I can raise an issue and, after review/agreement, submit a PR.
Some nice advice here https://pedestal.io/pedestal/0.8/reference/error-handling.html#_logging_uncaught_exceptions to consider overriding error handling to not log stylobate errors.
Stylobate errors can be interesting because they are unhandled exceptions.
We know that some are pure noise to most folks, and want to ignore those (`broken pipe` and probably Connection reset by peer).
I assume all other stylobate errors are interesting (unless we learn otherwise, case by case).
But sometimes these errors can be huge.
And sometimes they may contain sensitive info.
For cljdoc, I can probably sanitize and slim down the logged context. I'll have to figure out the best spot to do this in Pedestal.
Probably easiest to do it in a https://github.com/pedestal/pedestal/blob/fa2ac776e8246d5ade4eb8e1cc28df923cfb4bcb/servlet/src/io/pedestal/http/impl/servlet_interceptor.clj#L274-L289 and actually log from there, maybe a bit hacky because this was not the intended use of an exception-analyzer.