Follow-up from the account pools epic (#1464, PR #1514).
Current behavior (v1, accepted)
ccs cliproxy accounts order <provider> persists a DrainOrderConfig (manual or tier mode) and writes a top-level priority into each auth file. The mode survives re-auth, but the effective per-file priorities are lost when syncRegistryWithTokenFiles() rewrites auth state after a re-auth. The user must re-run --set or --by-tier to restore them. The order show command emits a drift warning when the stored order no longer matches the auth files, so the state is visible.
Requested change
Wire an automatic re-apply of the stored drain order into the registry sync path so priorities survive re-auth without a manual re-run.
Why it was deferred
Re-applying inside the sync path risks a loop: sync rewrites priority, the file watcher triggers a reload, which can trigger another sync. The fix needs an idempotency skip-check (only write when the computed priority differs from current file content) plus a test proving no reload loop. That caution was judged to outweigh the v1 benefit.
Acceptance
- After re-auth of any pooled account, effective priorities match the stored DrainOrderConfig without user action
- No watcher/reload loop (idempotency test: sync with already-correct priorities performs zero writes)
- Drift warning in
order show stays as a safety net
Follow-up from the account pools epic (#1464, PR #1514).
Current behavior (v1, accepted)
ccs cliproxy accounts order <provider>persists a DrainOrderConfig (manual or tier mode) and writes a top-levelpriorityinto each auth file. The mode survives re-auth, but the effective per-file priorities are lost whensyncRegistryWithTokenFiles()rewrites auth state after a re-auth. The user must re-run--setor--by-tierto restore them. Theorder showcommand emits a drift warning when the stored order no longer matches the auth files, so the state is visible.Requested change
Wire an automatic re-apply of the stored drain order into the registry sync path so priorities survive re-auth without a manual re-run.
Why it was deferred
Re-applying inside the sync path risks a loop: sync rewrites priority, the file watcher triggers a reload, which can trigger another sync. The fix needs an idempotency skip-check (only write when the computed priority differs from current file content) plus a test proving no reload loop. That caution was judged to outweigh the v1 benefit.
Acceptance
order showstays as a safety net