-
Notifications
You must be signed in to change notification settings - Fork 83
SDK-199 Auth Retry policy completely bypassed #987
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
base: master
Are you sure you want to change the base?
SDK-199 Auth Retry policy completely bypassed #987
Conversation
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## master #987 +/- ##
==========================================
+ Coverage 69.26% 69.41% +0.15%
==========================================
Files 109 109
Lines 8917 8926 +9
==========================================
+ Hits 6176 6196 +20
+ Misses 2741 2730 -11 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
Ayyanchira
left a comment
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.
Made some comments
| let timeIntervalToRefresh = TimeInterval(expirationDate) - dateProvider.currentDate.timeIntervalSince1970 - expirationRefreshPeriod | ||
| if timeIntervalToRefresh > 0 { | ||
| scheduleAuthTokenRefreshTimer(interval: timeIntervalToRefresh, isScheduledRefresh: true, successCallback: onSuccess) | ||
| resetRetryCount() |
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.
Schedule wont necessarily guarantees successful retrieval of token. Should we reset the count here?
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.
My understanding is that since the schedule is fired, we can reset the retries. regardless of its success.
| if pauseAuthRetry { | ||
| return true | ||
| } | ||
|
|
||
| // Scheduled refresh should never bypass retry safety limits. | ||
| if isInScheduledRefreshCallback { | ||
| return retryCount >= authRetryPolicy.maxRetry | ||
| } | ||
|
|
||
| return retryCount >= authRetryPolicy.maxRetry && !shouldIgnoreRetryPolicy |
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 looks simplified and better.
| if self.localStorage.email != nil || self.localStorage.userId != nil { | ||
| self.isInScheduledRefreshCallback = isScheduledRefresh | ||
| self.requestNewAuthToken(hasFailedPriorAuth: false, onSuccess: successCallback, shouldIgnoreRetryPolicy: isScheduledRefresh) | ||
| self.isInScheduledRefreshCallback = 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.
This part should be well tested manually as well
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'm leaning on these tests to cover this part:
- Refresh is queued and callback fires (scheduled refresh path hits the timer closure and requests a token)
- Skip refresh when there’s no email and no userId
- Scheduled refresh respects retry limits (this is specifically exercising isInScheduledRefreshCallback + shouldPauseRetry logic invoked inside the timer closure when isScheduledRefresh == true)
- Pausing retries blocks the refresh (this hits shouldSkipTokenRefresh before scheduling the timer)
🔹 Jira Ticket(s)
✏️ Description
Fixes auth retry for expired JWT refresh: scheduled token refresh no longer bypasses
pauseAuthRetriesorauthRetryPolicy.maxRetry, preventing runaway/infiniteonAuthTokenRequestedloops.Added unit tests to lock pause + maxRetry behavior on scheduled refresh, and reset retry count after a successful refresh is queued.