Open loewenheim opened 1 year ago
This issue has gone three weeks without activity. In another week, I will close it.
But! If you comment or otherwise update it, I will reset the clock, and if you label it Status: Backlog
or Status: In Progress
, I will leave it alone ... forever!
"A weed is but an unloved flower." ― Ella Wheeler Wilcox 🥀
Perhaps, we could have the installer automatically prompt the user to ask them whether they would like their installation to be instrumented; we would then store this option in our configuration file
It would be useful to instrument
sentry-cli
with Sentry so that nothing runs on the user end by default, but we can ask them to temporarily switch it on in case of crashes.More context
We do not currently instrument Sentry CLI with Sentry because users may not want us to know about how they are using Sentry CLI.
However, having Sentry instrumented in Sentry CLI might assist with debugging errors which are difficult for us to reproduce by allowing us to obtain from users a full stack trace of their error. https://github.com/getsentry/sentry-cli/pull/2189 was an attempt at allowing users to enable backtraces with the RUST_BACKTRACE=1 environment variable, but the change is insufficient because release builds don't include debug symbols, meaning that these stack traces are only really useful in a debug build.
To maintain user privacy, the Sentry instrumentation would be disabled by default, and would only be enabled when a certain environment variable (e.g. SENTRY_REPORT_ERROR) is set.
The CLI would then capture any errors that would crash the CLI and send them to Sentry, also outputting the event ID if this is possible.