Raised in the human review of #2556 (see #2556 (comment)). Follow-up to #2549.
The gap. The secretsNamespace stamp in oauth.json does not survive a save by an Inspector older than the namespace (≤ 2.9.x): the old parseOAuthPersistBlob → serializeOAuthPersistBlob round trip drops unknown keys. After a downgrade — or when two versions alternate on one state file — the old version sees no tokens (the legacy ids were deleted at adoption), and the next new-version save re-adopts under a fresh UUID. That leaves the previous namespace's entries orphaned in the secret store (possibly still-valid refresh tokens in the OS keychain) with no state file referencing them, so nothing will ever find or clear them.
What exists already. #2556 documents the hazard in docs/secret-storage.md (downgrading after adoption logs you out; alternating versions orphans entries). This issue is for a cleanup mechanism, if wanted.
Possible shapes (to be designed):
- On re-adoption, record the superseded namespace somewhere clearable, or purge its entries for the urls the file indexes before minting the new UUID.
- A standalone sweep (
--clear-orphaned-secrets?) that enumerates oauth+<ns>+… entries in the store and deletes those whose namespace no known state file carries — note the store API may not support enumeration on all backends (keyring cannot list), which may constrain this to the file backend.
Acceptance. Alternating 2.9.x and current on one state file does not permanently strand keychain entries, or the limitation is explicitly documented as unfixable per backend.
Raised in the human review of #2556 (see #2556 (comment)). Follow-up to #2549.
The gap. The
secretsNamespacestamp inoauth.jsondoes not survive a save by an Inspector older than the namespace (≤ 2.9.x): the oldparseOAuthPersistBlob → serializeOAuthPersistBlobround trip drops unknown keys. After a downgrade — or when two versions alternate on one state file — the old version sees no tokens (the legacy ids were deleted at adoption), and the next new-version save re-adopts under a fresh UUID. That leaves the previous namespace's entries orphaned in the secret store (possibly still-valid refresh tokens in the OS keychain) with no state file referencing them, so nothing will ever find or clear them.What exists already. #2556 documents the hazard in
docs/secret-storage.md(downgrading after adoption logs you out; alternating versions orphans entries). This issue is for a cleanup mechanism, if wanted.Possible shapes (to be designed):
--clear-orphaned-secrets?) that enumeratesoauth+<ns>+…entries in the store and deletes those whose namespace no known state file carries — note the store API may not support enumeration on all backends (keyring cannot list), which may constrain this to the file backend.Acceptance. Alternating 2.9.x and current on one state file does not permanently strand keychain entries, or the limitation is explicitly documented as unfixable per backend.