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.ConstraintViolation

View on GitHub (pinned to 71377f2769)

Solutions

  1. Retry GetMergeBlockers on a fresh connection/context; a mid-iteration rows.Err is usually transient.
  2. Raise the context timeout and the driver's read timeout if the conflict list is large or the server is slow.
  3. Check the dolt sql-server logs for the corresponding server-side error (disconnect, OOM, storage fault).
  4. 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

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


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