-
Notifications
You must be signed in to change notification settings - Fork 27
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
JWT improvements Part 1 #718
Conversation
1. Provide a method to stop JWT retries (regardless of retry policy) 2. Make it possible to specify a retry policy (on IterableConfig)
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## feature/JWTImprovement #718 +/- ##
=========================================================
Coverage ? 61.73%
=========================================================
Files ? 76
Lines ? 4728
Branches ? 536
=========================================================
Hits ? 2919
Misses ? 1506
Partials ? 303 ☔ View full report in Codecov by Sentry. |
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.
Added some comments @hardikmashru ! Really great PR.
Can we have a feature branch and first have all the changes merged into the feature branch first? That way we can test the entire branch once ready and then merge to master
.setMaxRetries(4) | ||
.setRetryBackoff(RetryPolicy.LINEAR) | ||
.setRetryInterval(2L) |
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.
This can go under one method -> config.setAuthRetryPolicy
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.
ok got it
@@ -355,6 +355,7 @@ private void onLogin(@Nullable String authToken) { | |||
return; | |||
} | |||
|
|||
pauseAuthRetries(false); |
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.
Thinking over - What if we call this method in setAuthToken
function?
That way, Not just during logging in, but also when setAuthToken is explicitly called, we can resume the retry functionality.
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.
@Ayyanchira I tried with that first, but setAuthToken is called internally from the SDK in the success scenario and in other methods which would reset the retry and pauseAuthRetry and break the retry logic we have written. Instead I have done this pauseAuthRetries call on the success of the API call so eventually in case of a valid token things will reset correctly.
iterableapi/src/main/java/com/iterable/iterableapi/IterableAuthManager.java
Outdated
Show resolved
Hide resolved
} | ||
|
||
void resetRetryCount() { | ||
if (retryCount > 0) retryCount = -1; |
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 about this.
Why is it not simply assigning the counter to 0?
Is it because there is a retry in progress which will increase the count to 0?
@@ -330,6 +330,8 @@ public void run() { | |||
|
|||
private void handleSuccessResponse(IterableApiResponse response) { | |||
IterableApi.getInstance().getAuthManager().resetFailedAuth(); | |||
IterableApi.getInstance().getAuthManager().pauseAuthRetries(false); |
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.
There could be success response for certain APIs which do not go through JWT check in the backend. Resetting auth could be problematic there. One such method is getRemoteConfiguration()
and in future - disableDevice
Either a bypass for the above method - getRemoteConfiguration
OR some other logic should be considered
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, we can put a check for these APIs and not call the pauseAuthRetries
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.
Looks like this is in progress. Will wait for the next part to comment on it.
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.
Retry Policy code is already there, I have just used an enum for the values.
Thanks. Yes, I can merge all into the one feature branch after other 2 points are done. What will be the name of the branch? |
-> feature/JWTRetryEnhancement |
* JWT improvements 1. Provide a method to stop JWT retries (regardless of retry policy) 2. Make it possible to specify a retry policy (on IterableConfig) * removed sample app changes * sample app revert * sample app revert * updates * Update IterableConfig.java * Update IterableRequestTask.java
@hardikmashru , lets have the base branch be a feature branch instead of However, I still see that retries firing off instantly and not respecting time intervals set especially when SDK makes |
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.
Added some last comments
iterableapi/src/main/java/com/iterable/iterableapi/IterableAuthManager.java
Outdated
Show resolved
Hide resolved
iterableapi/src/main/java/com/iterable/iterableapi/IterableRequestTask.java
Outdated
Show resolved
Hide resolved
Github actions - Checkstyle and a breaking unit test to be fixed before this can be merged in |
This will allow Iterable tester apps to read values from auth Manager for testing purpose
Instrumentation test fails due to yml changes which are there in master branch. And the changes has not propagated to feature/JWTImprovement. Hence skipping the instrumentation test. |
🔹 Jira Ticket(s) if any
✏️ Description