gastownhall/beads · error

checking dependencies for an existing primary key: %w

Error message

checking dependencies for an existing primary key: %w

What it means

Wraps a failure of `schemaHasPrimaryKey(ctx, db, "dependencies")` — introspection asking whether the dependencies table has any PRIMARY KEY at all. Like error 3973, this is a schema-metadata probe failing, before the repair decides whether to DROP the existing key.

Source

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

		// NULL-id rows behind it.
		return fmt.Errorf("migration 0053: %d dependencies row(s) have no depends_on_issue_id/depends_on_wisp_id/depends_on_external target and cannot be assigned an id (ck_dep_one_target should prevent this); repair manually before retrying", remainingNull)
	}

	idIsPrimaryKey, err := schemaColumnInPrimaryKey(ctx, db, "dependencies", "id")
	if err != nil {
		return fmt.Errorf("checking dependencies.id primary key: %w", err)
	}
	if idIsPrimaryKey {
		return nil
	}

	if _, err := db.ExecContext(ctx, "ALTER TABLE dependencies MODIFY COLUMN id CHAR(36) NOT NULL"); err != nil {
		return fmt.Errorf("finalizing dependencies.id for migration 0053: %w", err)
	}

	hasAnyPrimaryKey, err := schemaHasPrimaryKey(ctx, db, "dependencies")
	if err != nil {
		return fmt.Errorf("checking dependencies for an existing primary key: %w", err)
	}
	if hasAnyPrimaryKey {
		// The #4690 drifted shape has dependencies keyed some other way (or
		// keyless): a table can carry only one PRIMARY KEY, so whatever is
		// there must go before id can become it. The uk_dep_* natural-identity
		// unique keys (0043) enforce the real uniqueness independently of
		// whatever this was, so dropping it is safe.
		if _, err := db.ExecContext(ctx, "ALTER TABLE dependencies DROP PRIMARY KEY"); err != nil {
			return fmt.Errorf("dropping dependencies' existing primary key for migration 0053: %w", err)
		}
	}
	if _, err := db.ExecContext(ctx, "ALTER TABLE dependencies ADD PRIMARY KEY (id)"); err != nil {
		return fmt.Errorf("keying dependencies.id for migration 0053: %w", err)
	}
	return nil
}

// firstNonNullString returns the first valid (non-NULL) value among cols, or

View on GitHub (pinned to 71377f2769)

Solutions

1. Rerun `bd`; the probe is idempotent and read-only
2. Fix the wrapped %w root cause (connectivity, credentials, server health)
3. Verify access to information_schema.TABLE_CONSTRAINTS for the database
4. If crashes recur mid-repair, run the migration against a local copy first to confirm it completes

Example fix

// before: remote server unreachable mid-repair
bd dolt server start ; bd ready
// after: completes and restores primary key
bd ready

bd dolt sql -q "SELECT COUNT(*) FROM information_schema.TABLE_CONSTRAINTS WHERE TABLE_NAME='dependencies' AND CONSTRAINT_TYPE='PRIMARY KEY'" || echo 'introspection unavailable'

if err := ensureSchema(ctx, db); err != nil {
    if strings.Contains(err.Error(), "checking dependencies for an existing primary key") && transient(err) {
        return retryWithBackoff(ensureSchema)
    }
    return err
}

When it happens

Trigger: ensureDependenciesIDPrimaryKey runs right after MODIFY COLUMN; the information_schema query behind schemaHasPrimaryKey errors out (server down, permissions, transient connection failure, corrupt metadata).

Common situations: Same environments as 3973: Dolt daemon crash during multi-step repair, restricted DB user, flaky network to a remote Dolt server.

Related errors

• checking dependencies.id primary key: %w
• checking issues.%s: %w
• failed to scan peer for migration: %w
• failed to iterate peers for migration: %w
• failed to update encrypted password for peer %s: %w

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