Skip to content

Retry SQLITE_BUSY with backoff and jitter instead of failing the run #49

Description

@khaliqgant

Problem

A SQLITE_BUSY anywhere in a sync aborts it. The only mitigation today is the connection busy timeout (raised to 30s in #45), which is a single flat wait with no retry and no jitter.

For transient contention — several writers briefly overlapping — a bounded retry is strictly better than one long block: it releases the connection between attempts rather than holding it, and jitter prevents two syncs from re-colliding in lockstep after the same wait.

Note this does not help the permanently-held-lock case (a suspended process, see #47) — nothing does. This is specifically for normal overlap.

Proposal

Wrap chunk commits in a bounded retry: N attempts, exponential backoff with jitter, then fail with a message naming the contended resource. #46's ai-hist doctor already distinguishes transient contention from a wedged holder, so the error can point at the right remedy.

Consider whether 30s is still the right flat timeout once retry exists — a shorter timeout with retries may be more responsive than one long block.

Related: #45, #46, #47

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions