Description
The Java SDK cannot determine in-app frames for customer issues. In some cases, it does create it based on the app package identifier.
NOTE: Some Java SDKs do mark in-app frames: Spring Boot and Android.
NOTE: At the moment, this system will only work for customers using the GitHub integration. Other SCMs will need to invest in implementing the get trees repo functionality.
DISCLAIMER: For the privacy-conscious developer, source code contents are not used; only the file paths.
Relying on customers setting up their in-app frames with Stack Trace Rules is not successful.
Without in-app frames, the following Sentry features cannot work:
- Stack trace linking
- Code coverage linking (if applicable)
- GitHub pull request comments
- Suspect Commits
- Auto-assignments based on CODEOWNERS
Only a few projects have Java stack traces with in-app frames, thus, the Sentry experience is handicapped.
The idea is that we create a code mapping and a stack trace rule to map from the module or package in the error (e.g. com.foo.bar) to the file (com/foo/bar.java) representing the file in their repositories.
Automatically generating code mappings is based on the documented manual step of creating code mappings by developers.
We already derive code mappings for other languages (1). The novelty of this project is that we will also create the stack trace rules.
Once we derive the code mapping, we can add this stack trace rule for the project:
/* Sentry added this stack trace rule to have in-app frames */
stack.module:com.example.foo.** +app
Task list:
- Create tech spec, update RFC and communicate #84226
- Metrics for auto-source configs #84692
- Dry-run in-app rules & collect metrics
- Fix any errors from the dry-run stage
- Metrics to measure change
- Prepare docs for auto in-app stack trace rules
- Enable for EA & handle feedback
- Enable for GA & handle feedback
- Write changelog
- Remove options and feature flags