Embedded mode: wisp tables not auto-created (createIgnoredTables not called)

[sussdorff]

Bug

bd dep add and bd delete fail with table not found: wisp_dependencies in embedded mode (v1.0.0). The createIgnoredTables() function that creates the dolt_ignore'd wisp tables (wisps, wisp_dependencies, wisp_labels, wisp_events, wisp_comments) is never called during embedded Dolt initialization.

Reproduction

bd init   # or any existing embedded-mode repo
bd create --title="A" --type=task --priority=2
bd create --title="B" --type=task --priority=2
bd dep add <B-id> <A-id>
# Error: failed to check for dependency cycle: Error 1146: table not found: wisp_dependencies

Same for bd delete:

Error: getting dependencies: get dependencies from wisp_dependencies: Error 1146: table not found: wisp_dependencies

Environment

• bd version 1.0.0 (Homebrew)
• macOS, embedded Dolt mode (metadata.json: dolt_mode: "embedded")
• dolt_ignore patterns are correctly set (wisps, wisp_%)
• All 23 schema migrations ran successfully
• The dependencies table exists, but wisp_dependencies does not

Root Cause

createIgnoredTables() in internal/storage/dolt/migrations.go is called during server-mode schema init (initSchemaOnDB) but appears to not be called in the embedded Dolt code path. Since wisp tables are dolt_ignore'd, they only exist in the working set and must be recreated on every new Dolt session.

The cycle detection CTE in internal/storage/issueops/dependencies.go queries both dependencies and wisp_dependencies in a UNION. Unlike blocked.go which gracefully skips missing tables (isTableNotExistError → continue), the cycle detection query fails hard.

Workaround

Manually create the tables via dolt CLI:

dolt --data-dir=.beads/embeddeddolt sql -q "
CREATE TABLE IF NOT EXISTS wisps LIKE issues;
CREATE TABLE IF NOT EXISTS wisp_dependencies LIKE dependencies;
CREATE TABLE IF NOT EXISTS wisp_labels LIKE labels;
CREATE TABLE IF NOT EXISTS wisp_events LIKE events;
CREATE TABLE IF NOT EXISTS wisp_comments LIKE comments;
"

Tables persist in the working set after creation.

Suggested Fix

1. Call createIgnoredTables() during embedded Dolt initialization (same as server mode)
2. Additionally: make the cycle detection CTE in dependencies.go gracefully handle missing wisp_dependencies (like blocked.go already does)

[coffeegoddd]

What platform are you using beads on? I was not able to reproduce based on the steps above.

➜  beads_failure git:(main) ✗ bd init
  ✓ Configured Dolt remote: origin → git+https://github.com/coffeegoddd/dotfiles.git
  Repository ID: 66f66af7
  Clone ID: be90256e670cb94b

▶ Already configured as: maintainer
Change role? [y/N]: n
  Hooks installed to: .beads/hooks/
  ✓ Created AGENTS.md with agent instructions
Installing Claude hooks for this project...
✓ Registered SessionStart hook
✓ Registered PreCompact hook
Installing Claude Code integration...
✓ Created new CLAUDE.md with beads integration

✓ Claude Code integration installed
  File: /home/dustin/cursor_src/repros/beads_failure/CLAUDE.md
No additional configuration needed!

✓ Claude Code integration installed
  Settings: /home/dustin/cursor_src/repros/beads_failure/.claude/settings.json

Restart Claude Code for changes to take effect.

⚠ Git upstream not configured
  For sync workflows, set your upstream with:
  git remote add upstream <repo-url>


✓ bd initialized successfully!

  Backend: dolt
  Mode: embedded
  Database: beads_failure
  Issue prefix: beads_failure
  Issues will be named: beads_failure-<hash> (e.g., beads_failure-a3f2dd)

Run bd quickstart to get started.

➜  beads_failure git:(main) ✗ bd create --title="A" --type=task --priority=2

✓ Created issue: beads_failure-xj3 — A
  Priority: P2
  Status: open

➜  beads_failure git:(main) ✗ bd create --title="B" --type=task --priority=2

✓ Created issue: beads_failure-c2q — B
  Priority: P2
  Status: open

💡 Tip: Install the beads plugin for automatic workflow context, or run 'bd setup claude' for CLI-only mode
➜  beads_failure git:(main) ✗ bd list
○ beads_failure-c2q ● P2 B
○ beads_failure-xj3 ● P2 A

--------------------------------------------------------------------------------
Total: 2 issues (2 open, 0 in progress)

Status: ○ open  ◐ in_progress  ● blocked  ✓ closed  ❄ deferred
➜  beads_failure git:(main) ✗ bd dep add beads_failure-c2q beads_failure-xj3
✓ Added dependency: beads_failure-c2q (B) depends on beads_failure-xj3 (A) (blocks)
➜  beads_failure git:(main) ✗ bd list
○ beads_failure-c2q ● P2 B
○ beads_failure-xj3 ● P2 A

--------------------------------------------------------------------------------
Total: 2 issues (2 open, 0 in progress)

Status: ○ open  ◐ in_progress  ● blocked  ✓ closed  ❄ deferred
➜  beads_failure git:(main) ✗ bd version
bd version 1.0.0 (dev: main@72170267e00a)

[coffeegoddd]

Thanks for the report. I wasn't able to reproduce this with a fresh bd init — wisp tables are created correctly in that path. I believe the root cause analysis in the issue description is inaccurate. Here's what I think is actually happening:

Actual root cause: backfillMigrations skips wisp table creation

The embedded mode does create wisp tables — via SQL migrations 0020 and 0021. On a fresh bd init, all 23 migrations execute and the tables are created in the working set. They persist on disk between bd invocations (the .beads/embeddeddolt/ directory maintains Dolt working set state), so they survive across commands. This is why I can't reproduce it.

The problem is the backfill code path in internal/storage/embeddeddolt/schema.go (lines 83-91):

// If schema_migrations is empty but core tables already exist (e.g. restored
// from a DoltStore backup that doesn't track embedded migrations), backfill
// all versions so we don't re-run migrations that would fail on "already exists".
if current == 0 {
    var tableCount int
    if err := tx.QueryRowContext(ctx, "SELECT COUNT(*) FROM information_schema.tables WHERE table_name = 'issues' AND table_schema = DATABASE()").Scan(&tableCount); err == nil && tableCount > 0 {
        return backfillMigrations(ctx, tx)
    }
}

When the embedded engine finds schema_migrations empty but issues already exists, it marks all 23 migrations as applied without executing them. Migrations 0020-0021 (CREATE TABLE IF NOT EXISTS wisp_dependencies, etc.) never run, but they're recorded as version 23. On every subsequent invocation, migrateUp fast-paths (current >= latestVersion()) and the wisp tables are never created.

This triggers when upgrading from server-mode to embedded-mode (which v1.0.0 made the default). The embedded database gets bootstrapped with existing data, the issues table is already present, and the backfill path fires.

Why bd dep add fails but bd list works

The cycle detection CTE in issueops/dependencies.go:134 does a hard UNION ALL across dependencies and wisp_dependencies:

SELECT issue_id, depends_on_id FROM dependencies WHERE type IN ('blocks','conditional-blocks')
UNION ALL
SELECT issue_id, depends_on_id FROM wisp_dependencies WHERE type IN ('blocks','conditional-blocks')

If wisp_dependencies doesn't exist, this query fails with Error 1146. In contrast, blocked.go gracefully handles missing tables via isTableNotExistError + continue, so bd list works fine.

Suggested fix

1. After the backfill path, ensure wisp tables exist — run the wisp table CREATE TABLE IF NOT EXISTS statements after backfillMigrations returns, since those tables are dolt_ignore'd and wouldn't have been imported from the server-mode data.

@sussdorff — can you confirm you upgraded from a pre-v1.0 beads install (server mode) to v1.0.0 (embedded mode)? That would confirm this theory.

[sussdorff]

Yes, I upgraded from pre-v1.0 (shared-server mode) to v1.0.0 which switched to embedded mode as default. The backfill migration theory matches — the issues table already existed from the server-mode data, so the backfill path would have fired and skipped the wisp table creation.

Platform: macOS (Apple Silicon, Darwin 25.3.0), beads v1.0.0.

Separately: the dirty working set issue (dolthub/dolt#10807) also affects us — every remotesapi push from embedded mode dirties the remote SQL server's working set. We've been working around it with bd dolt pull && bd dolt push --force. PR dolthub/dolt#10810 should fix that side.