Skip to content

fix: coherent waiting message and self-healing keyring retry - #171

Merged
gnacho merged 4 commits into
mainfrom
fix/169-170-waiting-keyring
Aug 23, 2026
Merged

gnacho merged 4 commits into
mainfrom
fix/169-170-waiting-keyring

Conversation

@gnacho

@gnacho gnacho commented Aug 23, 2026

Copy link
Copy Markdown
Owner

Fixes #169 and #170.

#169 — coherent waiting message

When several folders are queued behind the shared permit, every row repeated the same 'Waiting for to finish…' (and could name a folder that was already synced). Now only the head of the queue names the folder it waits on; the rest use the generic 'Waiting for another folder to finish…'. The permit exposes waiter_count to know who is the head.

#170 — keyring stuck until restart

After login the Secret Service can be momentarily unavailable, so the first run reports a keyring-locked outcome and arms the flag. That flag only cleared on the next external trigger, which could never arrive, so the account stayed locked until the app restarted. Now a transiently locked keyring schedules a capped exponential backoff retry that re-reads the credentials and clears the flag once the service is ready. The budget is capped so a genuinely locked collection parks in the keyring-locked state instead of retrying forever.

Tests

  • queued_schedulers_only_name_the_holder_at_the_head
  • keyring_locked_schedules_its_own_retry
  • keyring_retry_budget_is_capped

Gate: 667 passed + 1 ignored, clippy/fmt clean.

gnacho added 4 commits August 23, 2026 12:02
When several folders are queued behind the shared permit, every row repeated
the same 'Waiting for <folder> to finish…' (and could name a folder that was
already synced). Only the head of the queue should name the folder it waits
on; the rest use the generic 'Waiting for another folder to finish…'.

The permit exposes waiter_count; a scheduler with no waiters ahead is the head
and names the holder, others stay generic.

Closes #169
After login the Secret Service can be momentarily unavailable, so the first
run reports a keyring-locked outcome and arms the keyring_locked flag. That
flag only cleared on the next external trigger, which may never arrive in the
session, so the account stayed 'keyring locked' until the app restarted.

On a keyring-locked outcome, schedule a capped exponential backoff retry that
re-enters the engine and re-reads the credentials; once the service is ready
the run succeeds and the flag clears on its own. The retry budget is capped
so a genuinely locked collection parks in the keyring-locked state instead of
retrying forever.

Tested: keyring_locked_schedules_its_own_retry, keyring_retry_budget_is_capped.

Closes #170
@gnacho
gnacho merged commit 1d4a4fd into main Aug 23, 2026
1 check passed
@gnacho
gnacho deleted the fix/169-170-waiting-keyring branch August 23, 2026 16:55
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.

Waiting message should only name the folder for the next queued folder

1 participant