Skip to content

Diagnostics Add diagnostics manager#785

Merged
tonidero merged 2 commits into
diagnosticsfrom
diagnostics-manager
Feb 16, 2023
Merged

Diagnostics Add diagnostics manager#785
tonidero merged 2 commits into
diagnosticsfrom
diagnostics-manager

Conversation

@tonidero

@tonidero tonidero commented Feb 9, 2023

Copy link
Copy Markdown
Contributor

Description

This PR is based on #784. Here we are adding the DiagnosticsManager which 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.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

All these WIPs will be addressed in future PRs.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

codecov Bot commented Feb 9, 2023

Copy link
Copy Markdown

Codecov Report

❗ No coverage uploaded for pull request base (diagnostics@74d6c21). Click here to learn what that means.
The diff coverage is n/a.

❗ Current head a6873d9 differs from pull request most recent head 51d8760. Consider uploading reports for the commit 51d8760 to get more accurate results

@@              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.

@tonidero tonidero force-pushed the diagnostics-jsonl-file-management branch from 313ca01 to b5e7f30 Compare February 10, 2023 11:12
@tonidero tonidero force-pushed the diagnostics-manager branch from 2c34b06 to a6873d9 Compare February 10, 2023 11:25
@tonidero tonidero marked this pull request as ready for review February 10, 2023 11:26
@tonidero tonidero requested a review from a team February 10, 2023 11:26

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We need diagnostics for diagnostics...
In all seriousness, I'm curious why all these are verbose?

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

+1

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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)

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

like, if we had error level for these, folks might get concerned but it won't affect their apps in any way

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah that makes sense, wanted to make sure I understood.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We don't usually add docstrings from what I've seen. But yeah, I can add this here 👍

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe

Suggested change
const val MAX_NUMBER_RETRIES = 3
const val MAX_NUMBER_POST_RETRIES = 3

Comment on lines 49 to 67

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wonder if this would be simpler like:

Suggested change
if (shouldRetry) {
val currentRetryCount = increaseConsecutiveNumberOfErrors()
if (currentRetryCount >= MAX_NUMBER_RETRIES) {
resetDiagnosticsStatus()
}
} else {
resetDiagnosticsStatus()
}
if (shouldRetry || increaseConsecutiveNumberOfErrors() >= MAX_NUMBER_RETRIES) {
resetDiagnosticsStatus()
}

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In the end, I added the logs Andy suggested below, so didn't do this change

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's make the behavior clearer:

Suggested change
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.")

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

+1

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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)

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

like, if we had error level for these, folks might get concerned but it won't affect their apps in any way

Base automatically changed from diagnostics-jsonl-file-management to diagnostics February 15, 2023 08:19
@tonidero tonidero force-pushed the diagnostics-manager branch from a6873d9 to 51d8760 Compare February 15, 2023 08:39
@tonidero tonidero merged commit 366b0c8 into diagnostics Feb 16, 2023
@tonidero tonidero deleted the diagnostics-manager branch February 16, 2023 08:58
tonidero added a commit that referenced this pull request Feb 17, 2023
…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.
tonidero added a commit that referenced this pull request Feb 22, 2023
…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.
tonidero added a commit that referenced this pull request Feb 28, 2023
tonidero added a commit that referenced this pull request Feb 28, 2023
…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.
tonidero added a commit that referenced this pull request Feb 28, 2023
tonidero added a commit that referenced this pull request Feb 28, 2023
…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.
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

Successfully merging this pull request may close these issues.

3 participants