gastownhall/beads · error
staging %s: %w
Error message
staging %s: %w
What it means
commitNonlocalRepair stages dolt_nonlocal_tables via CALL DOLT_ADD and commits with DOLT_COMMIT --skip-empty as part of healing partially-applied migrations 0040/0041. This error wraps a failure of the DOLT_ADD staging call itself. It means the Dolt stored-procedure call errored — connection drop, server-side procedure failure, or a non-committable working set.
Source
Thrown at internal/storage/schema/migration_repairs.go:84
// repairs, which normalise the table to the exact state each shipped
// (content-hashed, un-editable) migration body expects before it runs.
const nonlocalTablesName = "dolt_nonlocal_tables"
const nonlocalFrozenRowsInList = "('wisps', 'wisp_*', 'repo_mtimes', 'local_metadata')"
const nonlocalFrozenRowsValues = "('wisps', 'main', 'immediate'), ('wisp_*', 'main', 'immediate'), " +
"('repo_mtimes', 'main', 'immediate'), ('local_metadata', 'main', 'immediate')"
// commitNonlocalRepair commits a version-40/41 repair's edit to
// dolt_nonlocal_tables, staging that table BY NAME rather than with
// DOLT_COMMIT('-Am', ...). The scoping is load-bearing: on the bounded-migrate
// path (upTo != 0, where per-step commit is off) migrations 1..upTo sit
// uncommitted in the working set while the repair runs, and an "add all"
// commit here would sweep all of them into a repair-labeled commit. Staging
// only the table the repair touched leaves the rest of the working set exactly
// as the pass expects to find it. --skip-empty keeps the commit a clean no-op
// if the edit staged nothing.
func commitNonlocalRepair(ctx context.Context, db DBConn, message string) error {
if err := DrainCall(ctx, db, "CALL DOLT_ADD(?)", nonlocalTablesName); err != nil {
return fmt.Errorf("staging %s: %w", nonlocalTablesName, err)
}
return DrainCall(ctx, db, "CALL DOLT_COMMIT('-m', ?, '--skip-empty')", message)
}
// anyNonlocalFrozenRowPresent reports whether any of 0040's four
// dolt_nonlocal_tables rows currently exists (in the working set), the signal
// the version-40/41 repairs use to decide whether a heal is needed. Guarding on
// it keeps both repairs a strict no-op on the common (non-partial) path, so a
// fresh init reaches 0040/0041 having done no repair work at all — the repairs
// only ever touch a database that actually took the partial-apply brick.
func anyNonlocalFrozenRowPresent(ctx context.Context, db DBConn) (bool, error) {
var count int
if err := db.QueryRowContext(ctx,
"SELECT COUNT(*) FROM dolt_nonlocal_tables WHERE table_name IN "+nonlocalFrozenRowsInList).Scan(&count); err != nil {
return false, fmt.Errorf("counting nonlocal frozen rows: %w", err)
}
return count > 0, nil
}View on GitHub (pinned to 71377f2769)
Solutions
- Retry bd init — the repair is idempotent and guarded by anyNonlocalFrozenRowPresent
- Verify connectivity to the Dolt sql-server and overall health (bd doctor)
- Check that dolt_nonlocal_tables exists and the working set is not conflicted
- Inspect the wrapped underlying error (%w) for the real Dolt/SQL cause
Defensive patterns
Strategy: retry
Validate before calling
// before running migrations, confirm the server accepts queries
var one int
if err := db.QueryRowContext(ctx, "SELECT 1").Scan(&one); err != nil {
return fmt.Errorf("dolt server unreachable: %w", err)
} Try / catch
if err := runMigrations(ctx, db); err != nil {
if isTransient(err) { // bad connection / busy buffer
return runMigrations(ctx, db) // repairs are idempotent and presence-guarded
}
return err
} Prevention
- Run bd init against a stable, local-first Dolt connection rather than a flaky shared sql-server
- Retry init on transient connection errors — all repairs are idempotent
- Keep Dolt server/client versions aligned
- Avoid concurrent bd processes against the same database during migrations
When it happens
Trigger: Running bd init/migrations over a flaky shared sql-server where the connection drops mid-repair ("busy buffer" -> "bad connection"); dolt_nonlocal_tables missing or corrupted; Dolt server rejecting CALL DOLT_ADD while repairing 0040 or 0041.
Common situations: Transient network interruptions to a shared Dolt sql-server during upgrade; database partially bricked by a prior interrupted migration; Dolt server/client version mismatch.
Related errors
- clearing partial 0040 nonlocal rows: %w
- restoring pre-0041 nonlocal rows: %w
- read labels for %s: %w
- copy label %q for %s: %w
- read dependencies for %s: %w
AI-assisted analysis of gastownhall/beads@71377f2769 (2026-08-30).
Data as JSON: /api/errors/76376362daf9cd40.
Report an issue: GitHub.