gastownhall/beads · error
iterate schema conflicts: %w
Error message
iterate schema conflicts: %w
What it means
After scanning all rows from dolt_schema_conflicts, rows.Err() returned non-nil — the result-set iteration itself failed (connection drop, context cancellation, or engine error mid-stream). This is a transport/engine-level failure while reading the list, not a data problem.
Source
Thrown at internal/storage/versioncontrolops/conflicts.go:510
func schemaConflictTables(ctx context.Context, db DBConn) ([]string, error) {
rows, err := db.QueryContext(ctx, "SELECT table_name FROM dolt_schema_conflicts")
if err != nil {
if isMissingSystemTable(err) {
return nil, nil
}
return nil, fmt.Errorf("query schema conflicts: %w", err)
}
defer func() { _ = rows.Close() }()
var tables []string
for rows.Next() {
var t string
if err := rows.Scan(&t); err != nil {
return nil, fmt.Errorf("scan schema conflict: %w", err)
}
tables = append(tables, t)
}
if err := rows.Err(); err != nil {
return nil, fmt.Errorf("iterate schema conflicts: %w", err)
}
return tables, nil
}
// constraintViolationCounts lists the tables carrying outstanding constraint
// violations. mergesettle.go repairs the FK-cascade class on the auto path;
// anything it declined lands here, blocking the commit.
func constraintViolationCounts(ctx context.Context, db DBConn) ([]storage.ConstraintViolation, error) {
rows, err := db.QueryContext(ctx,
"SELECT `table`, num_violations FROM dolt_constraint_violations WHERE num_violations > 0")
if err != nil {
if isMissingSystemTable(err) {
return nil, nil
}
return nil, fmt.Errorf("query constraint violations: %w", err)
}
defer func() { _ = rows.Close() }()
var out []storage.ConstraintViolationView on GitHub (pinned to 71377f2769)
Solutions
- Retry GetMergeBlockers on a fresh connection/context; a mid-iteration rows.Err is usually transient.
- Raise the context timeout and the driver's read timeout if the conflict list is large or the server is slow.
- Check the dolt sql-server logs for the corresponding server-side error (disconnect, OOM, storage fault).
- Fix connection-pool settings (e.g. max lifetime) if connections are reclaimed mid-query.
Example fix
// before: single attempt, cancels on slow server
blockers, err := ops.GetMergeBlockers(ctx, db)
// after: retry transient failures with a longer deadline
run := func() (storage.MergeBlockers, error) {
c, cancel := context.WithTimeout(ctx, 120*time.Second)
defer cancel()
return ops.GetMergeBlockers(c, db)
}
blockers, err := run()
if err != nil && isTransient(err) { blockers, err = run() } Defensive patterns
Strategy: retry
Validate before calling
// Check connectivity before iterating large result sets:
if err := db.PingContext(ctx); err != nil { return err }
ctx, cancel := context.WithTimeout(ctx, 120*time.Second); defer cancel() Try / catch
if err != nil && strings.Contains(err.Error(), "iterate schema conflicts") {
time.Sleep(2 * time.Second)
blockers, err = ops.GetMergeBlockers(freshCtx, freshDB) // retry once
} Prevention
- Use generous context timeouts for merge diagnostics.
- Enable driver keepalives/reconnect for long sessions.
- Avoid cancelling the request mid-listing; let the iteration complete.
When it happens
Trigger: GetMergeBlockers iterating dolt_schema_conflicts when the connection drops, the context is cancelled, the dolt sql-server closes the result set, or the embedded engine errors mid-read (e.g. storage fault during a large conflict listing).
Common situations: Long interactive sessions where the connection times out during diagnosis; context deadlines expiring on slow servers; network flakiness between bd and a remote dolt sql-server.
Related errors
- iterate constraint violations: %w
- failed to remove backup: %w
- server not reachable: %w
- dolt server connection failed: %w
- dolt sql-server is not running on %s:%d; start it with 'bd d
AI-assisted analysis of gastownhall/beads@71377f2769 (2026-08-30).
Data as JSON: /api/errors/176a23dbd29d025f.
Report an issue: GitHub.