Arpad Borsos

> I believe this behavior is part of stable API and guaranteed to stay the same in the foreseeable future. Is this correct? If this is the case, I could...

I agree that the response itself might not be as useful. At this point the transport is dealing with `Envelope`s and it might be possible to at least debug-print the...

There is also the possibility of this being dropped in the transport due to rate limits and some such. Ideally, all the capturing methods would a Future that resolves to...

Are you capturing a lot of errors or transactions during an average request? I believe the problem here is simply that `backtrace` is slow. Especially if it is set up...

Lets reopen this, as this is a good thing to eventually do, maybe not right away though :-)

I had another look at this, and the situation is still quite bad. Due to not having stable accessors for either the `anyhow` backtrace, or `std::backtrace::Backtrace`, using `Display` is still...

> It looks like being able to not collect backtraces for unsampled transactions may help? Totally agree. That was changed quite a while back to follow the SDK spec. I...

This happens in the startup path (or when manually cloning a `Client`). Sentry does need to spawn two background threads. This `SessionFlusher`, and one for the configured `Transport`. I’m wondering...

> invalid item header, unknown variant `profile` That looks weird. Are you running an outdated self-hosted sentry by any chance?

What exactly do you mean by "grouping by exception"? Also, what is your expectation here? The panics are grouped by the stack trace by default, and not by the panic...