`in_app_exclude` does not work as intended.

[vaibagra]

Environment

What version are you running? Etc.
0.34

Steps to Reproduce

1. To exclude some of the generic crates that are not related to the core code path I was using in_app_exclude but it does not seem to exclude anything. On the docs it says: https://docs.rs/sentry/0.17.0/sentry/struct.ClientOptions.html#structfield.in_app_include:~:text=in_app_exclude%3A%20Vec,are%20never%20in_app
   I tried something like this:

in_app_exclude: vec![
            "backtrace",
            "futures",
            "futures_core",
            "hyper",
            "tokio",
            "tracing",
            "warp",
 ],

But it still does not exclude them for the stack trace.

Actual Result

This has been really annoying when trying to find the root cause of the issue. We prefer to use the sdk and not the issue grouping tab. Seems like a bug in the code?

[jacobsvante]

I haven't tried in_app_exclude, but in_app_include doesn't seem to work (at least as I expected) either.

Using in_app_include = vec!["my_app"] still marks function calls of other crates (such as futures) as In App.

[lcian]

Thanks for reporting this!

@vaibagra due to how things work at the moment in the SDK (https://github.com/getsentry/sentry-rust/blob/master/sentry-backtrace/src/process.rs), if you don't send any frame marked explicitly as in_app, then (almost) everything will be considered in_app anyway as shown in your screenshot.
We're looking to improve this. In the meantime, I would suggest you to also use in_app_include to explicitly mark frames you're interested in as in_app.

@jacobsvante if any frame associated with the event is marked as in_app by your in_app_include, then the feature should work as expected. If you have errors that don't involve any of your in_app modules, then you will fall back to the case I have described above where everything will be marked as in_app, so that might be the reason why you observe that it's not working.
Also, keep in mind that if you're running your app locally on a Mac, it's likely that everything will be marked as in_app anyways due to processing rules we apply in the backend. So please, run the app in e.g. a Linux container when testing this.

Let me know if you still observe different behaviour than what I described. If you do, please provide an example so that we can reproduce this.

[lcian]

I was mistaken, actually you don't need to mark anything explicitly as in_app, and both in_app_include and in_app_exclude will work as expected in normal cases.
There's some special cases such as those you get with futures_util or axum which we need to fix though.