gastownhall/beads · error

scan dolt_status: %w

Error message

scan dolt_status: %w

What it means

While iterating dolt_status rows in WorkingSetClean, each row is scanned into a single string (table_name). If rows.Scan fails — e.g. unexpected column count or type returned by the Dolt engine — the error is wrapped as "scan dolt_status: %w" and the function reports dirty-unknown by returning false plus the error.

Source

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

// changes, EXCLUDING dolt-ignored wisp tables ("wisps" and "wisp_*"), which
// cannot be staged/committed and so should never block a clean-working-set
// gate. This mirrors the exclusion in DirtyTableTracker.MarkDirty
// (commit.go), but — unlike the unexported workingSetClean in
// mergesettle.go, which does not exclude wisps and swallows its query
// error — this reports the error to the caller instead of treating it as
// dirty.
func WorkingSetClean(ctx context.Context, db DBConn) (bool, error) {
	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 {

View on GitHub (pinned to 71377f2769)

Solutions

1. Check the wrapped scan error and your Dolt/driver versions; align the client with the server's expected schema.
2. Upgrade beads / versioncontrolops to a version matching your Dolt engine version.
3. Test the query manually (SELECT table_name FROM dolt_status) to see the actual column shape.
4. Retry after restoring a compatible Dolt version.

Example fix

// before
rows, _ := db.QueryContext(ctx, "SELECT * FROM dolt_status") // schema drift
// after
rows, err := db.QueryContext(ctx, "SELECT table_name FROM dolt_status") // exact columns expected by Scan

rows, err := db.QueryContext(ctx, "SELECT table_name FROM dolt_status")
if err != nil { return err }
// probe schema compatibility before relying on WorkingSetClean
if _, err := db.QueryContext(ctx, "SELECT table_name FROM dolt_status LIMIT 1"); err != nil {
    return fmt.Errorf("dolt_status schema incompatible: %w", err)
}

clean, err := versioncontrolops.WorkingSetClean(ctx, db)
if err != nil && strings.Contains(err.Error(), "scan dolt_status") {
    log.Warn("dolt_status schema mismatch; check Dolt version compatibility")
    return err
}

When it happens

Trigger: Calling WorkingSetClean against a Dolt version whose dolt_status schema differs (extra columns, different column types), so a single-destination Scan fails; driver/driver-version mismatch.

Common situations: Upgrading or downgrading Dolt so the system table shape changed; using a generic SQL driver that returns extra columns for system tables; custom database/sql driver returning non-string types.

Related errors

• get dependency counts: scan blocker: %w
• scan dependency conflict: %w
• scan status: %w
• scan commit: %w
• failed to open server connection: %w

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