Repository navigation
qc 0.9.0: OAuth refresh tokens - #31
Merged
Merged
Conversation
…tEnvironments and getEnvironmentMetrics The quant-client SDK uses axios, which sets error.response.status, not error.statusCode. These three methods checked only statusCode, so a 401 showed 'Failed to fetch ...' instead of the 'run qc login' message.
The portal will issue quant-cli logins with a 90-day access token and a rotating refresh token. qc now: - refreshes the access token when 7 days or less are left, before the command runs (grant_type=refresh_token, client_id=quant-cli); - after a 401 from the v3 API (axios interceptor) or /api/oauth/user, refreshes once and repeats the request once, with no loop; - holds a lock file next to the credentials file (fs.open 'wx', 30 s stale timeout) while it refreshes, and reloads the stored login first. If another qc process already rotated the token, qc uses that result and sends nothing, so one refresh token is never sent twice (the portal revokes the whole chain on reuse); - keeps the stored refresh token when a response has none; - on invalid_grant/invalid_client, tells the user to run `qc login` and keeps the credentials file; - writes the credentials file atomically (temp file, mode 0600, rename), and takes the same lock for every read-modify-write of that file. Legacy logins have no refresh token or expiry. They are never refreshed, and their API clients keep the default axios with no retry.
With LOG_LEVEL=debug, qc login printed the token request body, which holds the authorization code and the code_verifier. Log only the token URL.
…ed files - Resolve the real path of the credentials file and write the temp file next to it, so a symlinked file (dotfiles manager) stays a symlink and its target is updated. - Retry the rename on EBUSY, EXDEV, EPERM and EACCES with a short backoff (antivirus and open handles on Windows). If it still fails, write the file in place with mode 0600 (the caller holds the lock). This keeps a single-file bind mount (docker -v ~/.quant/credentials:...) working. - Every read before a save (under the lock) now throws when the file cannot be read or parsed. Before, it got an empty config, and the save dropped every other platform. - The single-platform migration write and qc logout take the lock.
- The lock file holds a random nonce and the holder's own timestamp.
Staleness (90 s) comes from that timestamp, not from mtime.
- A stale lock is moved to a unique name first, checked to be the one
that was inspected, and only then removed. If another process replaced
it, it is put back. So two waiters cannot both take one stale lock.
- Release removes the file only if this holder's nonce is still in it.
- HeldLock.verify() lets a holder check ownership before it acts.
- While held: process.on('exit') removes the lock if this process owns
it, and SIGINT/SIGTERM wait until the locked work is done.
- If the record cannot be written, the new lock file is closed and removed.
… per process - If the save fails after the portal rotated the tokens, retry the save once, use the new pair for this command, and print where the save failed with "run qc login if later commands fail". - refreshIfDue runs at most once per platform in a process, so getEffectiveAuth and ApiClient.create never send the same refresh token twice, even after a failed save. - Check lock ownership just before the refresh request. - Refresh timeout 60 s (the portal can stall and still commits the rotation); "Renewing Quant login..." on stderr after 5 s. - The reload under the lock reads strictly: a broken file stops the refresh instead of looking like no login. - An ApiClient stops renewing after a renewed token also gets 401, so a polling loop cannot rotate the token on every request. - qc org list goes through ApiClient.getUserInfo(), so it gets the 401 retry.
The portal now recovers a lost rotation: the previous refresh token, sent again within 5 minutes and before the new access token was used, gets a new pair once. After an unknown outcome (timeout or abort, network error, 5xx, or a 200 body that cannot be read), qc keeps the lock, waits 20 s and sends the same refresh token once more. A 200 is saved as usual. Any other answer keeps the earlier behaviour. There is never more than one retry, and no retry after a definite 4xx. Both attempts and the wait can take up to 140 s, longer than the 90 s stale limit, so HeldLock.touch() verifies ownership and writes a new holder timestamp before and after the wait.
The portal answers the previous refresh token with "just rotated" for 30 s after a rotation, recovers a lost rotation once from 30 s to 5 minutes, and revokes after that. - invalid_grant "just rotated" is an unknown outcome, not a refusal: the token is not marked as refused and no "run qc login" warning is shown. - After an unknown outcome, qc waits 45 s after the previous attempt ended and sends the same refresh token again: at most 2 retries, and none when 4 minutes have passed since the first send. - Before each retry, qc reloads the credentials under the lock. If the stored token changed, it uses the stored tokens and sends nothing. - The lock is touched before and after each wait. The longest gap is one 60 s attempt, inside the 90 s stale limit. A waiter now waits up to 6 minutes, longer than the longest hold (about 5 minutes). - While the lock is held, a second Ctrl-C stops at once and removes the lock first (a signal kill emits no 'exit').
Found in the local e2e run: a dropped refresh response made qc wait 46 s with no output.
Review of 506faad: after the wait, the window may have passed or another process may have rotated the token, so no retry is sent.
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
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.
Release 0.9.0. qc refreshes its OAuth login with the refresh token, so the portal can issue 90-day scoped tokens to qc instead of non-expiring legacy tokens.
Changes
whoamishows expired / remaining days.fetch,AbortSignal.timeout). 0.8.0 already used globalfetch.Compatibility
refresh_token): login and all commands work; no refresh is attempted.develop, scoped tokens): login, refresh, 401 retry, 3 parallel processes (1 refresh), lost refresh response (recovered), revoked token (clearqc loginmessage, no loop).Tests
npm test: 226 passed. Build OK.Release
After merge: tag
v0.9.0on main;publish.ymlpublishes to npm. Then the portal switch for quant-cli (already on portaldevelop) can go to production.