Skip to content
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

Merged
merged 29 commits into from
May 13, 2024
Merged

Conversation

hardikmashru
Copy link
Collaborator

  1. Provide a method to stop JWT retries (regardless of retry policy)
  2. Make it possible to specify a retry policy (on IterableConfig)

🔹 Jira Ticket(s) if any

✏️ Description

Please provide a brief description of what this pull request does.

1. Provide a method to stop JWT retries (regardless of retry policy)
2. Make it possible to specify a retry policy (on IterableConfig)
Copy link

codecov bot commented Apr 3, 2024

Codecov Report

Attention: Patch coverage is 65.78947% with 13 lines in your changes are missing coverage. Please review.

❗ No coverage uploaded for pull request base (feature/JWTImprovement@e95295f). Click here to learn what that means.

❗ Current head 680b6fa differs from pull request most recent head 3bfe86d. Consider uploading reports for the commit 3bfe86d to get more accurate results

Files Patch % Lines
.../com/iterable/iterableapi/IterableAuthManager.java 47.36% 7 Missing and 3 partials ⚠️
.../java/com/iterable/iterableapi/IterableConfig.java 50.00% 2 Missing ⚠️
...ain/java/com/iterable/iterableapi/IterableApi.java 75.00% 1 Missing ⚠️
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.
📢 Have feedback on the report? Share it here.

Copy link
Member

@Ayyanchira Ayyanchira left a 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

Comment on lines 63 to 65
.setMaxRetries(4)
.setRetryBackoff(RetryPolicy.LINEAR)
.setRetryInterval(2L)
Copy link
Member

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

Copy link
Collaborator Author

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);
Copy link
Member

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.

Copy link
Collaborator Author

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.

}

void resetRetryCount() {
if (retryCount > 0) retryCount = -1;
Copy link
Member

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);
Copy link
Member

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

Copy link
Collaborator Author

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

Copy link
Member

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.

Copy link
Collaborator Author

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.

@hardikmashru
Copy link
Collaborator Author

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

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?

@Ayyanchira
Copy link
Member

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

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

@evantk91 evantk91 added the omni-cg PR's from OMNI CG label Apr 3, 2024
hardikmashru and others added 5 commits April 4, 2024 19:17
* 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
@Ayyanchira
Copy link
Member

@hardikmashru , lets have the base branch be a feature branch instead of master. Changes are looking great.

However, I still see that retries firing off instantly and not respecting time intervals set especially when SDK makes getMessages, getEmbeddedMessages and registerDevice call in the app startup.

@hardikmashru hardikmashru changed the base branch from master to feature/JWTRetryEnhancement April 11, 2024 14:02
@hardikmashru hardikmashru changed the base branch from feature/JWTRetryEnhancement to feature/JWTImprovement April 16, 2024 08:53
Copy link
Member

@Ayyanchira Ayyanchira left a 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

@Ayyanchira
Copy link
Member

Github actions - Checkstyle and a breaking unit test to be fixed before this can be merged in

@Ayyanchira
Copy link
Member

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.

@Ayyanchira Ayyanchira merged commit ec5ba3d into feature/JWTImprovement May 13, 2024
3 of 4 checks passed
@Ayyanchira Ayyanchira deleted the JWT_Imrovement_Part1 branch May 13, 2024 16:59
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
omni-cg PR's from OMNI CG
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants