What causes "seeding dolt_ignore pattern %q: %w" in gastownhall/beads?

Check the wrapped cause — read-only store is the most common cause; open the workspace read-write instead

seeding dolt_ignore pattern %q: %w

Error message

seeding dolt_ignore pattern %q: %w

What it means

This error wraps a failed INSERT of a missing pattern into the `dolt_ignore` table during migration seeding. seedDoltIgnorePatterns runs as part of MigrateUp to ensure known junk artifacts (e.g. backup files) are ignored, and this error means one of those INSERT IGNORE statements failed at the SQL level.

Source

Thrown at internal/storage/schema/schema.go:439

// read costs one round trip and removes the need for that grant.
//
// The write path is unchanged where a write is genuinely owed: INSERT IGNORE
// leaves existing rows untouched, so an explicit operator override (pattern
// present with ignored=false) is respected even in the race where the probe
// missed it. On an under-seeded database the new rows land in the working set
// and take effect immediately; who commits them depends on the pass: when
// migration work is needed, MigrateUp exempts dolt_ignore from the
// pre-existing-dirty guards as pass-owned state (same treatment as the
// aux-rekey tables) and stageSchemaTables commits it with the pass; on the
// no-work short-circuit, MigrateUp commits the seed itself in a scoped,
// labeled commit (keyed off the changed return value) so the heal converges
// in one pass instead of riding along inside an unrelated later commit.
func seedDoltIgnorePatterns(ctx context.Context, db DBConn) (bool, error) {
	changed := false
	for _, pattern := range missingDoltIgnorePatterns(ctx, db, doltIgnoreSeedCandidates(ctx, db)) {
		res, err := db.ExecContext(ctx, "INSERT IGNORE INTO dolt_ignore VALUES (?, true)", pattern)
		if err != nil {
			return changed, fmt.Errorf("seeding dolt_ignore pattern %q: %w", pattern, err)
		}
		// A RowsAffected error degrades to changed=false for that row: the
		// seed then stays an uncommitted working-set diff swept up by the
		// next commit, exactly the pre-scoped-commit behavior.
		if n, raErr := res.RowsAffected(); raErr == nil && n > 0 {
			changed = true
		}
	}
	return changed, nil
}

// commitSeededDoltIgnore stages and commits freshly seeded dolt_ignore rows
// in a scoped, labeled commit. Both MigrateUp paths use it: on the no-work
// short-circuit nothing downstream would ever commit the seed, and on the
// migration path the seed must be committed before the first step so an
// interrupted pass leaves a clean working set (#4566 self-heal contract).
func commitSeededDoltIgnore(ctx context.Context, db DBConn) error {
	if err := DrainCall(ctx, db, "CALL DOLT_ADD('dolt_ignore')"); err != nil {

View on GitHub (pinned to 71377f2769)

Solutions

Check the wrapped cause — read-only store is the most common cause; open the workspace read-write instead
Verify the dolt_ignore table schema matches `dolt_ignore VALUES(pattern, ignored)`
Confirm the Dolt working set is clean (`dolt status`) before migrating
Retry MigrateUp; seeding is idempotent (INSERT IGNORE with presence pre-check)

Example fix

// before: read-only open causes seed insert to fail
db := openStoreReadOnly(path)
schema.MigrateUp(ctx, db)
// after: migrate via a writable connection
db := openStoreReadWrite(path)
schema.MigrateUp(ctx, db)

Defensive patterns

Strategy: validation

Validate before calling

// check dolt_ignore is present and writable before migrating
if _, err := db.ExecContext(ctx, "SELECT * FROM dolt_ignore LIMIT 1"); err != nil {
	return fmt.Errorf("dolt_ignore unavailable: %w", err)
}

Try / catch

if _, err := schema.MigrateUp(ctx, db); err != nil {
	var derr *fs.PathError
	if errors.As(err, &derr) || strings.Contains(err.Error(), "read-only") {
		// reopen writable and retry
	}
}

Prevention

Always run migrations on a read-write connection
Keep the Dolt working set clean (`dolt status`) before migrating
Verify dolt_ignore schema matches the expected two-column shape

When it happens

Trigger: MigrateUp calling seedDoltIgnorePatterns on a database where `INSERT IGNORE INTO dolt_ignore VALUES (?, true)` errors — missing dolt_ignore table in an unexpected state, write to a read-only store, or a Dolt transaction/working-set conflict.

Common situations: Running `bd migrate` (or any command that triggers MigrateUp) against a read-only database; dolt_ignore exists but with an incompatible schema; Dolt server rejecting writes mid-migration.

Related errors

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