Rotating a shared credential instantly can break long-lived clients that still use the old version. A safer rollout introduces a new version, sends it to new connections, temporarily accepts both versions, and retires the old version only after migration.
Design a DualCredentialRotator class:
DualCredentialRotator(initialVersion) starts with one accepted credential version.beginRotation(nextVersion) starts an overlap period and returns whether it succeeded.versionForNewConnections() returns the version that new connections should use.accepts(version) returns whether that version is currently accepted.completeRotation() retires the old version and returns whether a rotation was completed.
When idle, only the current version is accepted and emitted. During rotation, both current and pending versions are accepted, but new connections receive the pending version. Beginning a rotation fails if another rotation is active or nextVersion already equals the current version. Completing a rotation while idle fails. Failed operations do not change state.
Example 1:
Input:
Output:
Explanation: The overlap keeps existing v1 connections working while new connections adopt v2. Completion retires v1.
Example 2:
Input:
Output:
Explanation: The failed nested rotation leaves green pending; red never becomes accepted or emitted.
Constraints
- Version names contain
1 to 100 printable ASCII characters and are case-sensitive. - Every object always has exactly one current version.
- At most one pending version may exist.
- At most
10^4 method calls are made.
Rotate Credentials Without Downtimemedium