Stabilize integrate-sqlite by handling transient SQLITE_BUSY in Dredd hooks

[Copilot]

integrate-sqlite was failing intermittently due to SQLITE_BUSY lock contention while Dredd hooks were creating prerequisite capability data. The hook process treated these transient lock errors as fatal, causing the job to exit.

• Root cause in hook capability setup

  • .dredd/hooks/capabilities.go performed capability writes without retry behavior for SQLite lock contention.
  • A transient DB lock during fixture creation caused a panic and terminated hooks.

• Concurrency + retry hardening

  • Serialized addCapabilities() execution with a package-level mutex to reduce concurrent write contention in hooks.
  • Added bounded retries (maxAttempts = 5) around capability resolution.
  • Added backoff using a named base delay constant:
    • const sqliteBusyRetryBaseDelay = 100 * time.Millisecond
    • delay progression: 1<<attempt * baseDelay

• Retry classification

  • Added isSQLiteBusyError(err) and retried only for lock-contention signatures:
    • SQLITE_BUSY
    • database is locked
    • database table is locked
  • Non-transient errors still fail fast.

const sqliteBusyRetryBaseDelay = 100 * time.Millisecond

for attempt := 0; attempt < maxAttempts; attempt++ {
    // resolveCapability(...)
    if err == nil {
        return
    }
    if !isSQLiteBusyError(err) {
        panic(err)
    }
    time.Sleep(time.Duration(1<<attempt) * sqliteBusyRetryBaseDelay)
}

[cursor]

Security review — no findings

Reviewed PR #3930 (.dredd/hooks/capabilities.go retry/mutex changes and go.mod/go.sum dependency cleanup).

Scope: Changes are confined to Dredd API-test hooks (CI-only; explicitly not for production) and indirect dependency tidying. No production API, auth, or request-handling code is modified.

Checked:

• Injection / unsafe deserialization — no new user-controlled input paths; caps and DB operations are driven by hardcoded test hooks.
• Authn/authz bypass — not applicable; test harness uses fixed admin tokens and local test DB setup.
• Error-string retry matching (isSQLiteBusyError) — only affects SQLite lock retries in CI; errors originate from the test DB layer, not remote attackers.
• Mutex + exponential backoff — serializes test DB setup under lock contention; no production DoS surface.
• Panic-to-error recovery — scoped to resolveCapability in test hooks; non-busy errors still panic immediately.
• Dependency changes (bbolt removal, golang.org/x/sync indirect version in pro/) — housekeeping only; no new runtime dependency with known CVE exposure introduced by this PR.

Prior threads: None from earlier automation runs.

Outcome: No medium, high, or critical vulnerabilities identified in added or modified code.

  

_{Sent by Cursor Automation: Find vulnerabilities}