-
-
Notifications
You must be signed in to change notification settings - Fork 444
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
Initial implementation of ANRv2 #2549
Conversation
|
Performance metrics 🚀
|
Revision | Plain | With Sentry | Diff |
---|---|---|---|
7a4e12e | 269.74 ms | 308.46 ms | 38.71 ms |
73f0b5d | 323.22 ms | 377.60 ms | 54.38 ms |
d504c21 | 363.02 ms | 435.73 ms | 72.71 ms |
9ca7f05 | 368.14 ms | 413.57 ms | 45.43 ms |
3b85ba6 | 363.41 ms | 417.52 ms | 54.11 ms |
App size
Revision | Plain | With Sentry | Diff |
---|---|---|---|
7a4e12e | 1.73 MiB | 2.35 MiB | 633.85 KiB |
73f0b5d | 1.73 MiB | 2.35 MiB | 633.85 KiB |
d504c21 | 1.73 MiB | 2.35 MiB | 633.84 KiB |
9ca7f05 | 1.73 MiB | 2.35 MiB | 633.85 KiB |
3b85ba6 | 1.73 MiB | 2.35 MiB | 633.74 KiB |
Codecov ReportPatch coverage:
Additional details and impacted files@@ Coverage Diff @@
## feat/anr-v2 #2549 +/- ##
=================================================
- Coverage 80.28% 80.01% -0.28%
- Complexity 3990 4131 +141
=================================================
Files 327 339 +12
Lines 15017 15582 +565
Branches 1977 2089 +112
=================================================
+ Hits 12057 12468 +411
- Misses 2183 2234 +51
- Partials 777 880 +103
... and 2 files with indirect coverage changes Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here. ☔ View full report in Codecov by Sentry. |
final ApplicationNotResponding error = | ||
new ApplicationNotResponding(message, Looper.getMainLooper().getThread()); | ||
final Mechanism mechanism = new Mechanism(); | ||
mechanism.setType("ANRv2"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure if we should keep it as ANRv2
or change it to ANR
? This way we can query on looker by mechanism I think and see who's sending new ANR events. But also, it'd be possible through the integration list.
The question here is rather: do the users care about this and want to see if the ANR has been reported using new mechanism?
@markushi re. serializing collections - I've checked, and actually all of our collections on scope are concurrent already (event |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice one, the earlier walkthrough definitely helped a lot when reviewing! I added a few minor comments about final
keywords and one suggestion for the JSON serializer APIs.
A few more thoughts:
-
I think we need to ensure that the same ANR won't be sent over and over again, ultimately DDoS-ing us in case something goes wrong along the whole process. I can see the marker file gets written in the
AndroidEnvelopeCache
aftersuper.store(...)
is called. Could it make sense to reverse the order here? Like first save the marker file and then store the envelope? If storing the envelope fails we'd loose the event, but we'd be safe from reporting the same ANR on every app start. -
The mechanism which ensures an ANR event is enriched with old disk data while no new data is written is A) adding the ANR integration at the beginning and B) having a single threaded executer service right?
sentry-android-core/src/main/java/io/sentry/android/core/ContextUtils.java
Outdated
Show resolved
Hide resolved
sentry-android-core/src/main/java/io/sentry/android/core/ContextUtils.java
Outdated
Show resolved
Hide resolved
sentry-android-core/src/main/java/io/sentry/android/core/ContextUtils.java
Outdated
Show resolved
Hide resolved
sentry-android-core/src/main/java/io/sentry/android/core/ContextUtils.java
Outdated
Show resolved
Hide resolved
sentry-android-core/src/main/java/io/sentry/android/core/DefaultAndroidEventProcessor.java
Outdated
Show resolved
Hide resolved
} catch (Throwable e) { | ||
options.getLogger().log(ERROR, "Error reading last ANR marker", e); | ||
} | ||
return 0L; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess that's technically not correct, but safe since this is way before Android was released 😅
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah pretty much my thoughts, but I didn't want to deal with nullable values here, so should be fine I guess 🤣
Yes, that's right. Even though it's a bit brittle, I've added a super sophisticated integration test in 6c51875, but I think this one is necessary as it tests exactly this scenario end-to-end. Not sure if we can do something better for now without changing even more in the pipeline which I'd really not want to do :D |
#skip-changelog
📜 Description
equals
/hashCode
for the protocol classes to be able to assert against them in testsUncaughtExceptionHint
public, because we were usingDiskFlushNotification
as a proxy for handling uncaught exceptions logic, now it's more explicit (and we also useDiskFlushNotification
for ANR events)💡 Motivation and Context
#1796
💚 How did you test it?
Automated and manually
📝 Checklist
sendDefaultPII
is enabled.🔮 Next steps
The PR is targeting integration branch to simplify PR review process. Other PRs to follow: