Make account metadata and token-vault updates recoverable #43

New Issue

2026-07-14T17:42:17Z

KofTwentyTwo commented

2026-07-14 17:42:17 +00:00

(Migrated from github.com)

Problem

Account metadata and token-vault changes are separate operations without compensation. Saving persists metadata and mutates in-memory state before storing the token. Deleting persists account removal before deleting the secret.

If Windows Credential Manager fails, saving can leave an account that has no usable credential, while deletion can leave an orphaned PAT. The same problem becomes more likely when adding macOS Keychain support, where lock state, entitlements, access control, or user interaction can fail independently.

Evidence

Save persists metadata and in-memory state before the vault write: gclo.ViewModels/AccountsStore.cs:59-99.
Delete persists metadata removal before vault deletion: gclo.ViewModels/AccountsStore.cs:102-119.

This finding was independently verified at commit 119ac26804ef93b98a262cb1c0c7a41afe71fde5. It is related to the account findings collected in #31 and #32, but is tracked separately as a consistency and secret-lifecycle bug.

Acceptance criteria

Save and delete define an explicit operation order and compensating behavior for every partial-failure point.
After any failure, in-memory state, accounts.json, and the token vault are either consistent or left in a documented recoverable state that the next operation can reconcile.
Updating an existing account cannot lose its prior working credential when the replacement vault write fails.
Deleting an account does not silently orphan a token; any unrecoverable cleanup failure is surfaced without exposing the token.
Contract tests cover metadata-write failure, vault-write failure, vault-delete failure, rollback failure, and idempotent retry.
No recovery or diagnostic path logs token values.

## Problem Account metadata and token-vault changes are separate operations without compensation. Saving persists metadata and mutates in-memory state before storing the token. Deleting persists account removal before deleting the secret. If Windows Credential Manager fails, saving can leave an account that has no usable credential, while deletion can leave an orphaned PAT. The same problem becomes more likely when adding macOS Keychain support, where lock state, entitlements, access control, or user interaction can fail independently. ## Evidence - Save persists metadata and in-memory state before the vault write: `gclo.ViewModels/AccountsStore.cs:59-99`. - Delete persists metadata removal before vault deletion: `gclo.ViewModels/AccountsStore.cs:102-119`. This finding was independently verified at commit `119ac26804ef93b98a262cb1c0c7a41afe71fde5`. It is related to the account findings collected in #31 and #32, but is tracked separately as a consistency and secret-lifecycle bug. ## Acceptance criteria - Save and delete define an explicit operation order and compensating behavior for every partial-failure point. - After any failure, in-memory state, `accounts.json`, and the token vault are either consistent or left in a documented recoverable state that the next operation can reconcile. - Updating an existing account cannot lose its prior working credential when the replacement vault write fails. - Deleting an account does not silently orphan a token; any unrecoverable cleanup failure is surfaced without exposing the token. - Contract tests cover metadata-write failure, vault-write failure, vault-delete failure, rollback failure, and idempotent retry. - No recovery or diagnostic path logs token values.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: KofTwentyTwo/gclo#43