Implement dynamic token stale period based on token TTL#677
Open
mihaimitrea-db wants to merge 6 commits intomainfrom
Open
Implement dynamic token stale period based on token TTL#677mihaimitrea-db wants to merge 6 commits intomainfrom
mihaimitrea-db wants to merge 6 commits intomainfrom
Conversation
Replace the fixed 5-minute stale window with a per-token formula: stale_period = min(TTL / 2, 20 minutes). This ensures that short-lived tokens (e.g. FastPath tokens with a 10-minute TTL) enter the stale window early enough to trigger a proactive async refresh, while long-lived tokens are capped at 20 minutes to maintain a meaningful refresh buffer under a 99.99% uptime SLA. The stale duration is computed at token fetch time using the remaining TTL as a proxy, since the SDK does not track token issuance timestamps. It is updated after every successful refresh (both synchronous and asynchronous) via computeStaleDuration(), and stored in a volatile field so that the unsynchronized fast-path read in getTokenAsync() sees a consistent value. Due to the exposed CachedTokenSource builder function setStalePeriod backwards compatibility is maintained through the useDynamicStalePeriod flag. Using the setStalePeriod function disables this flag, reverting the behaviour of the token cache to the legacy one.
…ion. Tests were failing because the TokenSource getToken function could return null tokens. Introduced null checks that only update the staleDuration if the refreshed token is not null. Otherwise the stale duration remains fixed as the null token will be marked as expired at the next call.
mihaimitrea-db
temporarily deployed
to
test-trigger-is
GitHub Actions
Inactive
mihaimitrea-db
temporarily deployed
to
test-trigger-is
GitHub Actions
Inactive
… legacy version and new dynamic one.
mihaimitrea-db
temporarily deployed
to
test-trigger-is
GitHub Actions
Inactive
|
If integration tests don't run automatically, an authorized user can run them manually by following the instructions below: Trigger: Inputs:
Checks will be approved automatically on success. |
mihaimitrea-db
temporarily deployed
to
test-trigger-is
GitHub Actions
Inactive
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Extends the token refresh buffer from a fixed 5 minutes to a dynamic period that adapts to token lifetime, improving reliability across different token types while maintaining backward compatibility.
The TTL is computed based on the remaining time to live at the moment the token is received and not its real TTL. For example, if the token has a TTL of 60 minutes but was acquired 20 minutes before being used by the SDK (e.g. through the CLI), its effective TTL will be 60 − 20 = 40 minutes.
Why
The previous 5 minute stale period barely covered the allowed monthly downtime of ~4.32 minutes. Thus, if the auth services were to be down and a request were to come 4 minute into the stale period it would have only 1 minute to obtain a new valid token before expiry. With an extended stale period of 20 minutes, the SDK has an extra ~15 minutes of stale but valid tokens to use, allowing the auth system to recover.
Changes
availability.
Backward compatibility:
Implementation:
Testing