Implement bounded transient database retries and accurate failure diagnostics #44

New issue

Closed

opened 2026-09-05 22:42:13 +00:00 by tophattedcat · 0 comments

tophattedcat commented

2026-09-05 22:42:13 +00:00

Owner

Problem

SPEC.md section 11 requires bounded retries for transient database contention. Plugin state operations currently translate SQLite errors directly into failures; connection timeout waiting is not an operation-level retry policy. The sync lock-failure test expects immediate failure.

The broad exception handler in sync also reports write failures as a playlist database that “could not be opened,” potentially attributing a beets write failure to the wrong store.

Proposed change

Retry known transient database failures at appropriate idempotent transaction boundaries. Preserve the original cause and identify the affected store and operation in user-facing diagnostics. Do not retry schema, constraint, permission, invalid-data, or persistent I/O failures. Account for any retries already provided by upstream stores.

Acceptance criteria

A transient busy/locked failure followed by success completes within a bounded retry budget.
Exhaustion fails non-zero; permanent failures are attempted once.
Retries do not duplicate memberships or lose intended item updates.
Failed full sync skips global pruning.
Read/open/write failures identify the correct operation and store.
Add network-free regression tests with controlled failures/backoff.

References: beetsplug/appleplaylists/state.py:111-161, sync.py:203-210, tests/test_sync.py:460. Audit finding 3 (medium).

## Problem SPEC.md section 11 requires bounded retries for transient database contention. Plugin state operations currently translate SQLite errors directly into failures; connection timeout waiting is not an operation-level retry policy. The sync lock-failure test expects immediate failure. The broad exception handler in sync also reports write failures as a playlist database that “could not be opened,” potentially attributing a beets write failure to the wrong store. ## Proposed change Retry known transient database failures at appropriate idempotent transaction boundaries. Preserve the original cause and identify the affected store and operation in user-facing diagnostics. Do not retry schema, constraint, permission, invalid-data, or persistent I/O failures. Account for any retries already provided by upstream stores. ## Acceptance criteria - A transient busy/locked failure followed by success completes within a bounded retry budget. - Exhaustion fails non-zero; permanent failures are attempted once. - Retries do not duplicate memberships or lose intended item updates. - Failed full sync skips global pruning. - Read/open/write failures identify the correct operation and store. - Add network-free regression tests with controlled failures/backoff. References: `beetsplug/appleplaylists/state.py:111-161`, `sync.py:203-210`, `tests/test_sync.py:460`. Audit finding 3 (medium).

tophattedcat referenced this issue from a commit

2026-09-06 11:16:26 +00:00

Fix sync and local workflows (#44 #45 #46 #47 #48 #49 #50)

tophattedcat referenced this issue from a pull request that will close it,

2026-09-06 11:16:27 +00:00

Fix sync reliability and local workflows for #44–#50 #51

tophattedcat closed this issue

2026-09-06 13:54:54 +00:00