Limit role of `Sentry.PlugCapture`?

[martosaur]

Problem Statement

The existence of Sentry.PlugCapture has been bothering me for a while, so I made a deep dive. Why does Sentry need a special Plug to report errors happening in Plug specifically?

The answer seems to be that back in the day those errors did not have a crash_reason metadata and thus Sentry's LoggerBackend could not report them off of a log event. When this was fixed in 2019 Sentry.PlugCapture was an established module and the solution to the double reporting problem was to ignore log messages with :cowboy domain 🙄

However, there was and is actually a valid reason for keeping it! Cowboy executes plug in a separate process and that means that its own log event is missing Sentry context. conn could still be sourced from the metadata, but anything set by Sentry.PlugContext is gone.

Since then, Bandit released and became the default choice for Phoenix webserver. It received the same treatment as Cowboy: Bandit tags all errors with :bandit domain and Sentry ignores them. However, Bandit runs code in the same process and does not suffer from the same problem as Cowboy. If you compare errors captured by Sentry.PlugCapture and handler/backend, they are pretty much identical.

Solution Brainstorm

All of the above makes me believe that Sentry.PlugCapture can be soft-deprecated and only recommended for Cowboy applications. As a user, I expect Sentry errors to be the same I see in logs and Sentry.PlugCapture side steps logging. Most of the time, this isn't noticeable, but as soon as you start tinkering with logs you realize that what is logged is not what is reported to Sentry. I imagine laying this all out will also help with the upcoming structured logging feature.

[whatyouhide]

I think this is a fantastic idea (and a great deep dive, thanks @martosaur!). Would you be open to draft a soft-deprecation docs update? We'd need to do it in both this repo and https://github.com/getsentry/sentry-docs.

[martosaur]

Sure, I'll take care of that!