ref(error-tracking): format clickhouse errors better

[MeredithAnya]

Cleans up how we record clickhouse errors in Sentry - we still will get the clickhouse stack trace, but we don't need to dump the whole stack trace in the error message itself

Before

After

[sentry-io]

🔍 Existing Issues For Review

Your pull request is modifying functions with the following pre-existing issues:

📄 File: snuba/web/db_query.py

Function	Unhandled Issue
_raw_query	QueryException: OOM command not allowed under OOM prevention. create... Event Count: 3

---

_{Did you find this useful? React with a 👍 or 👎}

[MeredithAnya]

We raise a QueryException later and I think we just end up double reporting to Sentry - if there is a reason to keep this line lemme know

[phacops]

That's good to remove the stack trace from the message itself.

Maybe we can still attach it to the error using https://develop.sentry.dev/sdk/data-model/event-payloads/exception/ ?

Also, I would separate the error code into an attribute and not as part of the message itself.

[untitaker]

a long time ago i wrote this sdk integration to parse clickhouse stacktraces and stitch them as stackframes into the event: https://docs.sentry.io/platforms/python/integrations/gnu_backtrace/

it's activated here:

snuba/snuba/environment.py

Line 83 in bb6bf85

GnuBacktraceIntegration(),

It worked for a while but I don't know if it works now.

[MeredithAnya]

@untitaker @phacops okie so i spent some time updating the sentry-python sdk - I think getsentry/sentry-python#4598 should work

That being said, I still think the changes in this PR are reasonable since we don't need the clickhouse stack trace reported multiple times