Diagnostics Add diagnostics manager#785
Conversation
There was a problem hiding this comment.
All these WIPs will be addressed in future PRs.
There was a problem hiding this comment.
The plan is to retry if there is a network/500 error but we didn't want to retry forever. Since an immediate retry would not solve all cases, we use shared preferences to store the number of retries through app restarts. Lmk what you think of that logic!
Currently I'm creating a new shared preferences file for this. Once we migrate to use a separate shared preferences file for the whole SDK, we could unify and have a single one, but for now, I thought it best to not use the app's shared preferences.
Codecov Report
@@ Coverage Diff @@
## diagnostics #785 +/- ##
==============================================
Coverage ? 81.85%
==============================================
Files ? 127
Lines ? 4133
Branches ? 520
==============================================
Hits ? 3383
Misses ? 544
Partials ? 206 Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here. |
313ca01 to
b5e7f30
Compare
2c34b06 to
a6873d9
Compare
There was a problem hiding this comment.
We need diagnostics for diagnostics...
In all seriousness, I'm curious why all these are verbose?
There was a problem hiding this comment.
I guess it's to prevent noise for folks actually debugging, since this isn't that much of a developer-facing feature (other than opting in)
There was a problem hiding this comment.
like, if we had error level for these, folks might get concerned but it won't affect their apps in any way
There was a problem hiding this comment.
Yeah, that's my thought on this. Since this is a non-critical feature, I thought we don't want to polute the logs with it. As mentioned before, lmk if you prefer to send errors/warnings and I can change it, not opposed to that approach either.
There was a problem hiding this comment.
Yeah that makes sense, wanted to make sure I understood.
There was a problem hiding this comment.
Not sure what other types in the Android codebase do, but it would help to have a quick docstring here summarizing what this type does.
There was a problem hiding this comment.
We don't usually add docstrings from what I've seen. But yeah, I can add this here 👍
There was a problem hiding this comment.
Maybe
| const val MAX_NUMBER_RETRIES = 3 | |
| const val MAX_NUMBER_POST_RETRIES = 3 |
There was a problem hiding this comment.
I wonder if this would be simpler like:
| if (shouldRetry) { | |
| val currentRetryCount = increaseConsecutiveNumberOfErrors() | |
| if (currentRetryCount >= MAX_NUMBER_RETRIES) { | |
| resetDiagnosticsStatus() | |
| } | |
| } else { | |
| resetDiagnosticsStatus() | |
| } | |
| if (shouldRetry || increaseConsecutiveNumberOfErrors() >= MAX_NUMBER_RETRIES) { | |
| resetDiagnosticsStatus() | |
| } |
There was a problem hiding this comment.
In the end, I added the logs Andy suggested below, so didn't do this change
There was a problem hiding this comment.
Let's make the behavior clearer:
| verboseLog("Error syncing diagnostics file: $error. Should retry: $shouldRetry") | |
| if (shouldRetry) { | |
| verboseLog("Error syncing diagnostics file: $error. Will retry the next time the SDK is initialized") | |
| } else { | |
| verboseLog("Error syncing diagnostics file: $error. This was the final attempt ($MAX_NUMBER_RETRIES). Deleting diagnostics file without posting.") |
There was a problem hiding this comment.
I guess it's to prevent noise for folks actually debugging, since this isn't that much of a developer-facing feature (other than opting in)
There was a problem hiding this comment.
like, if we had error level for these, folks might get concerned but it won't affect their apps in any way
a6873d9 to
51d8760
Compare
…795) ### Description Based on #793 This PR refactors previous code to split the `DiagnosticsManager` into `DiagnosticsTracker` and `DiagnosticsSynchronizer`. This is a prerequisite to avoid circular dependencies when tracking request data. - Before: `DiagnosticsManager`->`Backend`->`HttpClient`->`DiagnosticsManager`. - After: `DiagnosticsSynchronizer`->`Backend` for syncing and `HttpClient`->`DiagnosticsTracker` for tracking requests I could have tried to extract this logic from the HttpClient, but that would be a bigger refactor. This was the simplest solution I thought for this problem. Also, sorry I didn't see that issue before. I didn't modify the #785 PR directly to try to avoid some conflicts that would happen if I did it there directly.
…795) ### Description Based on #793 This PR refactors previous code to split the `DiagnosticsManager` into `DiagnosticsTracker` and `DiagnosticsSynchronizer`. This is a prerequisite to avoid circular dependencies when tracking request data. - Before: `DiagnosticsManager`->`Backend`->`HttpClient`->`DiagnosticsManager`. - After: `DiagnosticsSynchronizer`->`Backend` for syncing and `HttpClient`->`DiagnosticsTracker` for tracking requests I could have tried to extract this logic from the HttpClient, but that would be a bigger refactor. This was the simplest solution I thought for this problem. Also, sorry I didn't see that issue before. I didn't modify the #785 PR directly to try to avoid some conflicts that would happen if I did it there directly.
…795) ### Description Based on #793 This PR refactors previous code to split the `DiagnosticsManager` into `DiagnosticsTracker` and `DiagnosticsSynchronizer`. This is a prerequisite to avoid circular dependencies when tracking request data. - Before: `DiagnosticsManager`->`Backend`->`HttpClient`->`DiagnosticsManager`. - After: `DiagnosticsSynchronizer`->`Backend` for syncing and `HttpClient`->`DiagnosticsTracker` for tracking requests I could have tried to extract this logic from the HttpClient, but that would be a bigger refactor. This was the simplest solution I thought for this problem. Also, sorry I didn't see that issue before. I didn't modify the #785 PR directly to try to avoid some conflicts that would happen if I did it there directly.
…795) ### Description Based on #793 This PR refactors previous code to split the `DiagnosticsManager` into `DiagnosticsTracker` and `DiagnosticsSynchronizer`. This is a prerequisite to avoid circular dependencies when tracking request data. - Before: `DiagnosticsManager`->`Backend`->`HttpClient`->`DiagnosticsManager`. - After: `DiagnosticsSynchronizer`->`Backend` for syncing and `HttpClient`->`DiagnosticsTracker` for tracking requests I could have tried to extract this logic from the HttpClient, but that would be a bigger refactor. This was the simplest solution I thought for this problem. Also, sorry I didn't see that issue before. I didn't modify the #785 PR directly to try to avoid some conflicts that would happen if I did it there directly.
Description
This PR is based on #784. Here we are adding the
DiagnosticsManagerwhich is in charge of coordinating the diagnostics logic like calling the backend and handling the jsonl files. There are some WIPs to be addressed in future PRs.