gastownhall/beads · error

failed to commit dependency key repairs: %w

Error message

failed to commit dependency key repairs: %w

What it means

After applying all rekeys/removals inside an explicit transaction, repairDependencyKeys calls tx.Commit(); if commit fails the repairs are rolled back and the error is wrapped as "failed to commit dependency key repairs: %w". This indicates the fix did NOT persist and should be re-run once the cause is resolved.

Source

Thrown at cmd/bd/doctor/fix/dep_keys.go:150

				fmt.Printf("  Re-keyed %s row %s → %s\n", a.Table, mk[0], mk[1])
			}
		}
		for _, id := range a.NullTarget {
			//nolint:gosec // G201: table is a hardcoded constant, never user input.
			if _, err := tx.Exec(fmt.Sprintf(`DELETE FROM %s WHERE id = ?`, a.Table), id); err != nil {
				fmt.Printf("  Warning: failed to remove %s row %s: %v\n", a.Table, id, err)
				failed++
				continue
			}
			removed++
			repairedTables[a.Table] = true
			if showIndividual {
				fmt.Printf("  Removed %s row %s (no dependency target)\n", a.Table, id)
			}
		}
	}
	if err := tx.Commit(); err != nil {
		return fmt.Errorf("failed to commit dependency key repairs: %w", err)
	}

	// Commit changes in Dolt, staging only the repaired tables so an unrelated
	// dirty working set is not swept under this message. Best effort: commit
	// advisory; repair already applied.
	if len(repairedTables) > 0 {
		for table := range repairedTables {
			_, _ = db.Exec("CALL DOLT_ADD(?)", table)
		}
		_, _ = db.Exec("CALL DOLT_COMMIT('-m', 'doctor: re-key dependency ids to deterministic values')")
	}

	if failed > 0 {
		fmt.Printf("  Dependency keys: %d re-keyed, %d removed, %d FAILED — failed rows keep their old keys; resolve the warnings above and re-run bd doctor\n",
			rekeyed, removed, failed)
		return nil
	}
	fmt.Printf("  Fixed dependency keys: %d re-keyed, %d removed\n", rekeyed, removed)

View on GitHub (pinned to 71377f2769)

Solutions

1. Re-run the dependency keys fix after confirming the server is healthy — the transaction rolled back cleanly so a retry is safe
2. Check Dolt server logs and disk space for storage-side causes
3. Avoid running concurrent bd write operations against the same database during repairs

Example fix

// before
err := repairDependencyKeys(ctx, db, verbose) // failed to commit dependency key repairs
// after: retry with a fresh scan/commit cycle
for i := 0; i < 3; i++ {
	if err := repairDependencyKeys(ctx, db, verbose); err == nil {
		break
	}
}

if err := db.PingContext(ctx); err != nil {
	return fmt.Errorf("DB connection unstable, postponing commit-dependent repair: %w", err)
}
// Also check disk headroom on the DB host if commits failed before.

if err := repairDependencyKeys(ctx, db, verbose); err != nil {
	if strings.Contains(err.Error(), "failed to commit") {
		// transaction rolled back; a full retry is safe
		time.Sleep(backoff)
		return repairDependencyKeys(ctx, db, verbose)
	}
	return err
}

When it happens

Trigger: tx.Commit() fails after repairs were staged: Dolt server connection lost during the repair loop, server crashed/restarted, deadlock or lock conflict with another writer, or storage errors underneath the transaction.

Common situations: Dolt server with --no-auto-commit dropping the connection during a long repair; concurrent `bd` process mutating the same dependency rows causing conflicts; disk full on the database host.

Related errors

• failed to commit is_blocked repairs to Dolt: %w
• failed to begin transaction: %w
• failed to commit orphaned dependency removals: %w
• failed to commit dependency removals: %w
• failed to commit cross-table duplicate removals: %w

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