gastownhall/beads · error

iterate dolt_status: %w

Error message

iterate dolt_status: %w

What it means

After iterating dolt_status rows, WorkingSetClean calls rows.Err() to catch any error that occurred during row iteration (connection drop mid-scan, server-side failure). Such an error is wrapped as "iterate dolt_status: %w" so a dropped connection is reported rather than misread as a clean working set.

Source

Thrown at internal/storage/versioncontrolops/fastforward.go:79

	rows, err := db.QueryContext(ctx, "SELECT table_name FROM dolt_status")
	if err != nil {
		return false, fmt.Errorf("query dolt_status: %w", err)
	}
	defer rows.Close()

	clean := true
	for rows.Next() {
		var table string
		if err := rows.Scan(&table); err != nil {
			return false, fmt.Errorf("scan dolt_status: %w", err)
		}
		if table == "wisps" || strings.HasPrefix(table, "wisp_") {
			continue
		}
		clean = false
	}
	if err := rows.Err(); err != nil {
		return false, fmt.Errorf("iterate dolt_status: %w", err)
	}

	return clean, nil
}

// FastForwardAdopt fast-forwards the current branch to ref via
// CALL DOLT_MERGE('--ff-only', ref). ref must already be cached locally
// (e.g. a remote-tracking ref updated by a prior fetch); this performs no
// fetch of its own and fails if the merge would not be a pure fast-forward.
func FastForwardAdopt(ctx context.Context, db DBConn, ref string) error {
	if err := issueops.ValidateRef(ref); err != nil {
		return fmt.Errorf("invalid ref: %w", err)
	}

	if _, err := db.ExecContext(ctx, "CALL DOLT_MERGE('--ff-only', ?)", ref); err != nil {
		return fmt.Errorf("fast-forward to %s: %w", ref, err)
	}
	return nil

View on GitHub (pinned to 71377f2769)

Solutions

1. Retry WorkingSetClean after confirming the connection is healthy (db.PingContext).
2. Enable/idle-timeout-safe connection pooling or use a single dedicated connection for the check.
3. Investigate server-side logs for why the result stream aborted.
4. Honor the wrapped error's cause (context deadline vs connection reset) and adjust timeouts.

Example fix

// before
clean, err := versioncontrolops.WorkingSetClean(ctx, db) // flaky connection
// after
if err := db.PingContext(ctx); err != nil { return err }
clean, err := versioncontrolops.WorkingSetClean(ctx, db)
if err != nil && isTransient(err) {
    clean, err = versioncontrolops.WorkingSetClean(ctx, db) // retry once
}

if err := db.PingContext(ctx); err != nil {
    return fmt.Errorf("connection unhealthy before iteration: %w", err)
}

var clean bool
var err error
for attempt := 0; attempt < 3; attempt++ {
    clean, err = versioncontrolops.WorkingSetClean(ctx, db)
    if err == nil || !isTransient(err) { break }
    time.Sleep(time.Duration(1<<attempt) * 100 * time.Millisecond)
}

When it happens

Trigger: The database connection drops or the Dolt server restarts while rows are being streamed; context cancellation during iteration; network interruption on a remote sql-server connection.

Common situations: Long-lived connection hitting an idle timeout mid-iteration; flaky network to a remote Dolt server; server killed by OOM while serving the query.

Related errors

• iterate conflicts for table %s: %w
• failed to open server connection: %w
• failed to begin transaction: %w
• failed to recompute is_blocked: %w
• failed to commit is_blocked repairs: %w

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