Skip to content

arch: state backend silent error swallowing — add retry, circuit-breaker, startup verification #864

Closed

Description

@diberry

Problem

Silent failures: git-notes and orphan-branch state backends silently swallow git errors instead of surfacing them.

Consequences:

  • Operators are blind to data corruption until too late
  • State reads/writes fail silently; user doesn't know state is stale
  • Retryable errors (network blips) are not retried
  • Cascading failures: one corrupted state op cascades through all subsequent ops

Examples

  • git-notes backend fails silently on \git notes add\ error
  • orphan-branch backend silently catches git push failures
  • No logging, no metrics, no alerts

Proposed solution

  1. Retry + backoff: Retryable errors (transient git failures) should retry with exponential backoff
  2. Circuit-breaker: After N consecutive failures, circuit-breaker trips and fast-fails subsequent ops
  3. Startup verification: On CLI startup, verify state backend is healthy (can read/write test data)
  4. Observable errors: Surface errors to user (not silent swallow), log with context (repo, operation, git error)

Success criteria

  • Transient git errors are retried with backoff
  • Circuit-breaker prevents cascading failures
  • State backend health checked at CLI startup
  • All state backend errors are logged and user-visible
  • Operators can diagnose state corruption from logs/metrics

Activity

  1. diberry commented on Apr 6, 2026

    @diberry
    ContributorAuthor

    ✈️ Flight — Issue-Level PRD

    Summary

    The git-notes and orphan-branch state backends silently swallow git errors, leaving operators blind to data corruption until users report symptoms. This issue adds retry/backoff for transient failures, a circuit-breaker to prevent cascading failures, startup health verification, and observable error surfacing across all state backend operations.

    Problem Statement

    • State read/write errors are caught and silently discarded — no logging, no user notification
    • Transient git failures (network blips, lock contention) are not retried
    • One corrupted state op cascades through all subsequent operations in the session
    • Operators have zero visibility into state backend health until catastrophic failure

    Proposed Approach

    Phase 1 — Observable Errors (P0, smallest useful change)

    • Replace all silent catch {} blocks in git-notes and orphan-branch backends with logged, user-visible warnings
    • Add structured error context: operation, repo, git command, stderr output
    • No retry, no circuit-breaker — just make failures visible

    Phase 2 — Retry with Backoff (P1)

    • Add exponential backoff retry (3 attempts, 1s/2s/4s) for transient git errors
    • Classify errors: retryable (network, lock) vs permanent (auth, corruption)
    • After max retries, surface the error (Phase 1 path)

    Phase 3 — Circuit-Breaker + Startup Verification (P2)

    • Circuit-breaker: after N consecutive failures (default 5), fast-fail subsequent ops for a cooldown period
    • Startup verification: on CLI startup, run a read/write roundtrip test against the state backend
    • Surface circuit-breaker state in squad doctor output

    Acceptance Criteria

    • Zero silent catch {} blocks remain in state backend code
    • All state backend errors are logged with operation context
    • Transient git errors are retried with exponential backoff (configurable)
    • Circuit-breaker trips after N consecutive failures and fast-fails subsequent ops
    • squad doctor reports state backend health status
    • CLI startup performs state backend read/write roundtrip verification
    • Existing tests updated to verify error surfacing (not silent swallowing)

    Architecture Notes

    • State backends: packages/squad-sdk/src/state/ (git-notes, orphan-branch)
    • Error classification should be a shared utility — other backends may need it
    • Circuit-breaker state should be in-memory per session, not persisted
  2. added 2 commits that reference this issue on Apr 7, 2026
    61aec08
    17243f4
  3. diberry commented on Apr 10, 2026

    @diberry
    ContributorAuthor

    🔒 On hold — high-touch architecture work, focusing on low/medium-touch items first.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or improvement

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions