gastownhall/beads · error

failed to stage is_blocked repairs: %w

Error message

failed to stage is_blocked repairs: %w

What it means

After the transaction commits, repairBlockedState stages the issues table with CALL DOLT_ADD('issues') so the corrected is_blocked flags become a Dolt commit that syncs. This error wraps a failed DOLT_ADD — the repairs exist only in the Dolt working set and will not sync; if left unstaged they could be wiped by the next pull. The function treats this as fatal so success is never reported for an uncommitted repair.

Source

Thrown at cmd/bd/doctor/fix/blocked.go:86

		return fmt.Errorf("failed to recompute is_blocked: %w", err)
	}
	if err := tx.Commit(); err != nil {
		return fmt.Errorf("failed to commit is_blocked repairs: %w", err)
	}

	if changed == 0 {
		fmt.Println("  is_blocked already consistent — nothing to fix")
		return nil
	}

	// Persist the corrected flags as a Dolt commit, staging only issues — the
	// synced table is_blocked lives on (wisps are dolt_ignore'd). This path keeps
	// its own fresh-DB lifecycle rather than the shared store helper, but it must
	// not report success on a failed commit: a swallowed DOLT_COMMIT error would
	// leave the repair in the working set only, silently undone by the next pull.
	// bd doctor is server-mode only, so the server supplies the commit identity.
	if _, err := db.ExecContext(ctx, "CALL DOLT_ADD(?)", "issues"); err != nil {
		return fmt.Errorf("failed to stage is_blocked repairs: %w", err)
	}
	if _, err := db.ExecContext(ctx, "CALL DOLT_COMMIT('-m', 'doctor: recompute is_blocked for all issues')"); err != nil && !issueops.IsNothingToCommitError(err) {
		return fmt.Errorf("failed to commit is_blocked repairs to Dolt: %w", err)
	}

	fmt.Printf("  Recomputed is_blocked: %d row(s) corrected\n", changed)
	return nil
}

View on GitHub (pinned to 71377f2769)

Solutions

  1. Check the wrapped %w cause; if the Dolt repo is in a conflicted/merge state, resolve it (`dolt status`, resolve conflicts, `dolt add`/commit or abort the merge) and rerun the fix.
  2. Verify the issues table exists and is tracked: `dolt sql -q "select count(*) from issues"` and `dolt status` inside .beads/dolt; re-stage manually with `dolt add issues` if the working set holds the corrections.
  3. Confirm server/version compatibility — ensure the running dolt sql-server supports CALL DOLT_ADD with a bind parameter (upgrade an outdated server).
  4. Rerun `bd doctor --fix` after repairing repo state; then verify with `dolt log` that a 'doctor: recompute is_blocked for all issues' commit lands and `bd dolt push` succeeds.

Example fix

// before (repo stuck mid-merge)
err: failed to stage is_blocked repairs: working set has conflicts

// after: clear the merge state first, then retry
// dolt abort-merge (in .beads/dolt) or resolve conflicts, then:
if err := fix.RecomputeBlocked("."); err != nil {
	log.Fatalf("blocked-state fix failed: %v", err)
}
Defensive patterns

Strategy: try-catch

Validate before calling

// Verify the Dolt repo is in a clean, non-merge state and issues is tracked
out, err := exec.Command("dolt", "status", "--json").Output()
if err != nil || bytes.Contains(out, []byte("conflict")) || bytes.Contains(out, []byte("merge")) {
	log.Fatal("dolt working set dirty/conflicted — resolve before blocked-state fix")
}

Type guard

func canStageIssues(ctx context.Context, db *sql.DB) bool {
	var n int
	err := db.QueryRowContext(ctx,
		"SELECT COUNT(*) FROM dolt_status WHERE `table` = 'issues'").Scan(&n)
	return err == nil // issues table present in repo status
}

Try / catch

if err := fix.RecomputeBlocked(path); err != nil && strings.Contains(err.Error(), "failed to stage is_blocked repairs") {
	// repairs sit in the working set only; resolve dolt state, then re-run
	// (or manually: dolt add issues && dolt commit -m "doctor: recompute is_blocked")
	log.Printf("staging failed, working set holds uncommitted repairs: %v", err)
}

Prevention

When it happens

Trigger: Calling fix.RecomputeBlocked when `CALL DOLT_ADD(?)` with 'issues' fails: the issues table is dolt_ignore'd or not a tracked table in this repo, the Dolt working-set state is inconsistent (e.g. a merge/conflict state left by a crashed sync), the session lost its database context, or the wrapped SQL call itself errored on the server.

Common situations: A previous bd sync/pull crashed leaving the Dolt repo mid-merge, so DOLT_ADD refuses to stage; the database was re-initialized so 'issues' is not the expected tracked table name; server version mismatch where DOLT_ADD stored-procedure signatures differ; repo state where issues lives under a different table name than the doctor fix assumes.

Related errors


AI-assisted analysis of gastownhall/beads@71377f2769 (2026-08-30). Data as JSON: /api/errors/2106a14e71cdfc93. Report an issue: GitHub.