[SDK-369] no push reregister on token refresh#1003
[SDK-369] no push reregister on token refresh#1003franco-zalamena-iterable wants to merge 9 commits intomasterfrom
Conversation
franco-zalamena-iterable
force-pushed
the
bugfix/no-push-reregister-on-token-refresh
branch
from
68f10bc to
6bc8f7b
Compare
franco-zalamena-iterable
force-pushed
the
bugfix/no-push-reregister-on-token-refresh
branch
from
db3f49f to
bc065e5
Compare
|
Wait for bugbash to be completed |
franco-zalamena-iterable
changed the title
Now we are recreating the token and starting the auto retry
franco-zalamena-iterable
force-pushed
the
bugfix/no-push-reregister-on-token-refresh
branch
from
bc065e5 to
6d3a0b7
Compare
![github-advanced-security[bot]](https://avatars.githubusercontent.com/in/57789?s=60&v=4){kind=small}
iterableapi/src/main/java/com/iterable/iterableapi/IterableApi.java
Dismissed
Show dismissed
Hide dismissed
franco-zalamena-iterable
changed the title
franco-zalamena-iterable
changed the title
| checkAndUpdateAuthToken(authToken); | ||
| _setUserSuccessCallbackHandler = successHandler; | ||
| _setUserFailureCallbackHandler = failureHandler; | ||
| onLogin(authToken, email, true, merge, replay, false, failureHandler); |
There was a problem hiding this comment.
The checkAndUpdateAuthToken(authToken) call is now redundant on the setEmail and setUserId methods because the onLogin() will always do updateAuthToken(authToken)
There was a problem hiding this comment.
good catch, latest commit addresses this
| * When the new token arrives, AuthTokenReadyListeners are notified via the | ||
| * INVALID → UNKNOWN state transition. | ||
| */ | ||
| void handleAuthTokenRejection() { |
There was a problem hiding this comment.
This called from IterableTaskRunner.processTask() on a worker thread.
Multiple concurrent 401s could race through the method.
The scheduleAuthTokenRefresh is internally sync'd on timerLock, so it won't double-schedule, but the resetFailedAuth() + getNextRetryInterval() sequence could yield different retry intervals under contention
There was a problem hiding this comment.
i reverted this to what we had on master, will keep this refactor for a different ticket to reduce complexity and possible errors
…ceiving a valid JWT when in the invalid state
…k to valid, fire getMessages, syncEmbedded and registerDeviceToken
4 participants
🔹 Jira Ticket(s) if any
✏️ Description
Fixed a problem with completeuserlogin retrigger
Decoupling the completeUserLogin from the SetAuthToken flow. Those live independently now.
Summary
setAuthToken replaced with updateAuthToken. This only handles the update of the auth token without the side effects of login. If the user expects a login flow, the setEmail should be called. This prevents unnecessary calls to the backend on token refreshes