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
- Check the wrapped underlying error (%w) for the real cause — usually connectivity or permissions.
- Verify the DB connection is alive and the server is up, then re-run `bd` so the repair retries.
- Confirm the user has SELECT on information_schema / SHOW TABLES privileges.
- 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
- Run migrations on a healthy, verified DB connection (ping first).
- Grant the migration user SELECT on information_schema.
- Avoid killing the process mid-upgrade; let the guarded repair finish.
- Keep Dolt server version compatible with the bd schema migrations.
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
- checking %s.id for the pre-0058 repair: %w
- checking dependencies.id primary key: %w
- checking dependencies for an existing primary key: %w
- checking issues.%s: %w
- pre-repair for migration %s: %w
AI-assisted analysis of gastownhall/beads@71377f2769 (2026-08-30).
Data as JSON: /api/errors/d8a8b07a00576280.
Report an issue: GitHub.