Skip to content

feat(credentials): cache account passwords in memory - #180

Merged
gnacho merged 1 commit into
mainfrom
feat/178-credential-cache
Aug 23, 2026
Merged

gnacho merged 1 commit into
mainfrom
feat/178-credential-cache

Conversation

@gnacho

@gnacho gnacho commented Aug 23, 2026

Copy link
Copy Markdown
Owner

Closes #178

What

One Secret Service session negotiation per account per process instead of one per credential lookup (the pattern desktop clients like Iotas use):

  • get_for_account serves an in-memory cache first; keyring resolutions populate it
  • set writes through, delete evicts
  • A sync run ending in AuthFailed invalidates the cached password, so the next lookup re-reads the keyring after the user signs in again

Before: up to 3 SecretService::connect(Dh) per lookup x every folder x every few minutes.

Tests

  • cache_serves_until_invalidated, set_writes_through_and_delete_evicts, auth_failed_outcome_invalidates_the_cached_password
  • Gate: 670 passed, fmt/clippy clean, red-green verified on the engine invalidation

One Secret Service session negotiation per account per process instead of
one per credential lookup (the pattern desktop clients like Iotas use):
every get_for_account used to open a fresh DH session, and a sync run did
several. The cache is written through on set, evicted on delete, and
invalidated when a run ends in AuthFailed so the next lookup re-reads the
keyring after the user signs in again.
@gnacho
gnacho merged commit 9ecf0b8 into main Aug 23, 2026
3 of 4 checks passed
@gnacho
gnacho deleted the feat/178-credential-cache branch August 23, 2026 21:16
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Cache account credentials in memory instead of per-sync Secret Service reconnects

1 participant