gastownhall/beads · error

checking wisp_dependencies table: %w

Error message

checking wisp_dependencies table: %w

What it means

After handling wisps, the pre-0047 repair probes for wisp_dependencies via INFORMATION_SCHEMA.TABLES. This error wraps failure of that probe — the catalog lookup itself failed (connection error, server issue), not merely the table being absent.

Source

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

// 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
	}

	return ensureWispDependenciesSplitTargets(ctx, db)
}

// ensureWispIsBlockedForRecompute repairs a drift shape in ignored/0006's own
// guard: it no-ops (SELECT 1) when wisps does not exist yet at the moment it
// runs, and once the ignored cursor advances past 6 that migration is never
// pending again (pending = version > MAX(cursor); a missing low-numbered row
// does not lower the high-water mark). wisps can be materialized without
// is_blocked several ways -- ignored/0001's own CREATE-then-RENAME leaves an
// existing wisps table untouched, and the main-side 0047 repair above

View on GitHub (pinned to 71377f2769)

Solutions

1. Retry bd init after restoring connectivity — steps re-probe the schema
2. Check Dolt server health with bd doctor
3. Verify the server version supports the INFORMATION_SCHEMA queries used
4. Inspect the wrapped error for the underlying 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 = 'wisp_dependencies'`).Scan(&n)
// err != nil here means the same probe the repair uses will fail

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

When it happens

Trigger: bd init pre-0047 repair on a clone where wisp_dependencies was never synced locally (dolt_ignore'd) and the INFORMATION_SCHEMA.TABLES lookup fails due to a dropped connection or server error.

Common situations: Clone-skew window after a schema bump (#4695/#4176); transient network outage during upgrade; overloaded shared Dolt server.

Related errors

• checking wisps 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/ef3ccb0e19a8f557. Report an issue: GitHub.