Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

in_app_exclude does not work as intended. #717

Open
vaibagra opened this issue Dec 20, 2024 · 2 comments
Open

in_app_exclude does not work as intended. #717

vaibagra opened this issue Dec 20, 2024 · 2 comments

Comments

@vaibagra
Copy link

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

Image

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
Copy link

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 lcian added bug and removed bug labels Jan 29, 2025
@lcian
Copy link
Member

lcian commented Feb 17, 2025

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants