gastownhall/beads · error

checking wisps table: %w

Error message

checking wisps table: %w

What it means

ensureWispTablesForMixedBlockedRecompute probes for the wisps table before migration 0047's recompute block, which joins wisps unconditionally. This error wraps failure of the INFORMATION_SCHEMA.TABLES existence probe itself — the catalog query failed (connection error, server problem), distinct from the table simply being absent.

Source

Thrown at internal/storage/schema/migration_repairs.go:202

// The created shape must be forward-canonical, not the original 0020/0021
// content: this repair fires at v47, but the SAME empty tables then ride
// through every later main migration in the same pass, including 0053 --
// which INSERTs wisps.no_history/started_at into issues (added by 0023/0027,
// after 0020) and, on a database whose local wisp_dependencies predates
// 0022, expects idx_wisp_dep_type to already exist. Creating the 0020/0021-era
// shape here is exactly the #4695 bug shape one migration later: a real
// production repro hit "table not found: wisps" at 0047 and "unknown column
// no_history" at 0053 back to back (see the failed-workaround log in #4695).
// wispsTableDDLForMigration0047 / wispDependenciesTableDDLForMigration0047
// below are therefore the full shape as of immediately before 0053 runs --
// every column/index any main migration <=52 adds to these tables -- verified
// by building a bounded fresh chain (migrations 1..52 only) and comparing
// against SHOW CREATE TABLE, not by manual inspection. Nothing from 54/55
// (lease columns added then removed again) or 56 belongs here.
func ensureWispTablesForMixedBlockedRecompute(ctx context.Context, db DBConn) error {
	hasWisps, err := schemaTableExists(ctx, db, "wisps")
	if err != nil {
		return fmt.Errorf("checking wisps table: %w", err)
	}
	if !hasWisps {
		if _, err := db.ExecContext(ctx, wispsTableDDLForMigration0047); err != nil {
			return fmt.Errorf("creating wisps for migration 0047: %w", err)
		}
	}

	hasWispDeps, err := schemaTableExists(ctx, db, "wisp_dependencies")
	if err != nil {
		return fmt.Errorf("checking wisp_dependencies table: %w", err)
	}
	if !hasWispDeps {
		if _, err := db.ExecContext(ctx, wispDependenciesTableDDLForMigration0047); err != nil {
			return fmt.Errorf("creating wisp_dependencies for migration 0047: %w", err)
		}
		return nil
	}

View on GitHub (pinned to 71377f2769)

Solutions

1. Retry bd init once connectivity is stable
2. Verify Dolt sql-server health (bd doctor)
3. If INFORMATION_SCHEMA queries consistently fail, check Dolt server version compatibility
4. Inspect the wrapped error for the underlying SQL/network cause

// pre-check the catalog probe path
var n int
err := db.QueryRowContext(ctx, `SELECT COUNT(*) FROM INFORMATION_SCHEMA.TABLES
  WHERE TABLE_SCHEMA = DATABASE() AND TABLE_NAME = 'wisps'`).Scan(&n)
// err != nil here means the same probe the repair uses will fail

hasWisps, err := schemaTableExists(ctx, db, "wisps")
if err != nil {
    if isTransient(err) {
        return ensureWispTablesForMixedBlockedRecompute(ctx, db) // idempotent re-probe
    }
    return err
}

When it happens

Trigger: bd init reaching the pre-0047 repair on a clone with cursor skew (#4695/#4176) while the INFORMATION_SCHEMA.TABLES lookup for 'wisps' fails — dropped connection to the shared Dolt sql-server or a server error.

Common situations: Clone whose schema_migrations cursor is behind after a schema bump; transient network outage during upgrade; overloaded shared Dolt server.

Related errors

• checking wisp_dependencies table: %w
• failed to update encrypted password for peer %s: %w
• staging %s: %w
• counting nonlocal frozen rows: %w
• clearing partial 0040 nonlocal rows: %w

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