gastownhall/beads · error

checking %s for the pre-0058 repair: %w

Error message

checking %s for the pre-0058 repair: %w

What it means

This error wraps a failure while probing whether a table (wisp_dependencies, wisps, or issues) exists, via schemaTableExists, before running the pre-0058 forward-shape repair. The repair bails out silently (nil) when a table is missing, but if the existence CHECK itself errors — typically a metadata query failure against the Dolt/MySQL information schema — the underlying error is wrapped with this message. It indicates the repair could not even determine the database's shape.

Source

Thrown at internal/storage/schema/wisp_dep_forward_repair.go:130

	{"uk_wisp_dep_external_target", "ADD UNIQUE KEY uk_wisp_dep_external_target (issue_id, depends_on_external)"},
	{"idx_wisp_dep_type_issue", "ADD INDEX idx_wisp_dep_type_issue (type, depends_on_issue_id)"},
	{"idx_wisp_dep_type_wisp", "ADD INDEX idx_wisp_dep_type_wisp (type, depends_on_wisp_id)"},
	{"idx_wisp_dep_type_external", "ADD INDEX idx_wisp_dep_type_external (type, depends_on_external)"},
}

// repairWispDependenciesForwardShape is the pre-0058 repair. It no-ops on every
// population except the one 0058 cannot serve: no-ops when the table or either
// referenced table is absent, when the table is already in the final shape, and
// on a fresh store (which never had the generated column, so 0058 applies to it
// cleanly).
func repairWispDependenciesForwardShape(ctx context.Context, db DBConn) error {
	// Both referenced tables must exist before any foreign key can be added.
	// 0058 carries the same @has_wisps/@has_issues guards; a database missing
	// one is left untouched rather than assumed into a shape it may not have.
	for _, t := range []string{wispDepTable, "wisps", "issues"} {
		exists, err := schemaTableExists(ctx, db, t)
		if err != nil {
			return fmt.Errorf("checking %s for the pre-0058 repair: %w", t, err)
		}
		if !exists {
			return nil
		}
	}

	needed, err := wispDepNeedsForwardRepair(ctx, db)
	if err != nil {
		return err
	}
	if !needed {
		return nil
	}

	if err := deleteWispDepRowsRejectedByFinalShape(ctx, db); err != nil {
		return err
	}
	if err := dropWispDepLegacyShape(ctx, db); err != nil {

View on GitHub (pinned to 71377f2769)

Solutions

  1. Check the wrapped underlying error (%w) for the real cause — usually connectivity or permissions.
  2. Verify the DB connection is alive and the server is up, then re-run `bd` so the repair retries.
  3. Confirm the user has SELECT on information_schema / SHOW TABLES privileges.
  4. If metadata is corrupt, restore from backup or re-initialize the database and re-import from issues.jsonl export.

Example fix

// before (caller ignoring migration failure)
repairWispDependenciesForwardShape(ctx, db) // panic: checking wisps for the pre-0058 repair: driver: bad connection
// after
if err := repairWispDependenciesForwardShape(ctx, db); err != nil {
    log.Fatalf("schema repair failed, check DB connectivity: %v", err)
}
Defensive patterns

Strategy: try-catch

Validate before calling

// before relying on the repair
rows, err := db.QueryContext(ctx, "SELECT 1 FROM information_schema.TABLES WHERE TABLE_NAME = 'wisp_dependencies'")
if err != nil {
    log.Fatalf("metadata unreachable — check connectivity/privileges before running bd: %v", err)
}
rows.Close()

Try / catch

if err := repairWispDependenciesForwardShape(ctx, db); err != nil {
    var driverErr driver.Error
    if errors.As(err, &driverErr) && driverErr.Code() == errnoBadConnection {
        // reconnect and retry the guarded repair
    }
    return fmt.Errorf("pre-0058 repair aborted during table check: %w", err)
}

Prevention

When it happens

Trigger: repairWispDependenciesForwardShape calls schemaTableExists(ctx, db, t) and the underlying SHOW FULL TABLES / information_schema query returns an error (connection drop, permissions, corrupt metadata, server shutdown mid-migration).

Common situations: Database connection lost during startup migration; the bd process lacks privileges to read information_schema; Dolt server restarting while an upgrade runs; metadata corruption after a crashed migration.

Related errors


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