ref(backtrace): add entries and extra logic for in-app detection#756
ref(backtrace): add entries and extra logic for in-app detection#756
Conversation
| // these are not modules but things like __rust_maybe_catch_panic | ||
| "__rust_", | ||
| "___rust_", | ||
| "rust_begin_unwind", |
There was a problem hiding this comment.
This is always the top frame for panics and ends up in the high level issue description, I would rather have the first in-app frame there
Unless it's intended that we have rust_begin_unwind there?
| "futures_core::", | ||
| "futures_util::", |
There was a problem hiding this comment.
We should not add too specific stuff but this seems common enough to be here
| } else { | ||
| func_name = func_name.trim_start_matches('<').trim_start_matches("_<"); | ||
| func_name = func_name | ||
| .trim_start_matches("<F as ") |
There was a problem hiding this comment.
Specific case that can be commonly observed in raw frames related to futures_core, futures_util, axum, hyper, and others
It's specific for those cases as in general we will see the form <X as Y> for trait impls but I don't see any downside with adding this.
Swatinem
left a comment
There was a problem hiding this comment.
detecting this in the SDK requires these symbols to be present at runtime, which is often not the case when one is using a stripped release build.
Ideally the border frame should be added to our default stack trace enhancement rules that are part of serverside grouping, and are also applied after serverside symbolication.
I'll do some more research and submit a PR to add more frames there. |
Description
Closes #717