Track a credential generation without logging tokens
OAuth 2.0 allows a refresh response to issue a replacement refresh token; when issued, the client must replace the old token. Provider rotation and reuse rules vary. This synthetic plan elects one refresh owner and stores access/refresh references as one generation.
| Worker | Observation | Decision |
|---|---|---|
| A | Generation 7 access token expired; refresh credential still eligible; A obtains refresh ownership | Refresh once and commit generation 8 |
| B | Generation 7 access token expired; A owns refresh | Wait boundedly, then reread generation |
| A response contains new refresh token | Replacement required by response contract | Commit both references before releasing ownership |
Resolve refresh uncertainty before retrying
Use a bounded owner lease or equivalent recovery design so a crashed worker cannot block forever. A lost refresh response may invalidate the old token under the actual provider’s rules; do not run an unlimited retry loop. Preserve nonsecret error context and follow the supported reauthorisation path when required.
Worker B receives an older refresh response after generation 8 is stored. Should it overwrite the store?
Show the worked answer
No. Compare the expected credential generation and reject the stale commit. Investigate whether that response changed provider state; local ordering alone cannot determine token validity.