Known Issues — 3.1.0¶
Known issues affecting 3.1.0, each with a workaround. If you hit something not listed here, please report it in the raise-commons issue tracker.
rai graph build --prune has no effect¶
Symptom. rai graph build --prune completes but stale nodes on a synced
remote graph server are not removed; --cross-repo queries can return
symbols that no longer exist in any current checkout.
Cause. Remote pruning is deliberately suppressed while the server-side
keyspace is repo-wide. The flag is accepted and ignored, and says so in the
command's own --help.
Workaround. None needed for local work — the local graph index is
rebuilt per checkout (rai graph build) and is always consistent. If you run
against a graph server and stale remote nodes get in the way, re-push the
graph from the owning checkout; the stale entries are cosmetic and do not
affect local queries.
If you saw this on an earlier page
Earlier versions of this page grouped this with the worktree-scoping
problem — graph nodes scoped per repo instead of per checkout, so queries
could return symbols from another worktree. That one is fixed and ships
in 3.1.0. The --prune suppression is a separate consequence of the
remote keyspace being repo-wide, and is still current.
Resolved in the release-candidate line¶
The following issues were present in the beta line and are resolved in 3.1.0.
Graph queries returned symbols from another worktree (RAISE-15607)¶
Was: graph_nodes keyed on the repo slug rather than the checkout, so
every worktree of the same repo shared one keyspace in ~/.rai/raise.db. The
last rai graph build clobbered the nodes of every other worktree, and a query
run in worktree A could return symbols whose source_file belonged to
worktree B — different code, different branch, silently wrong.
Fix: graph nodes are now scoped by checkout, and
validate_asserted_root() enforces per-checkout isolation.
"database is locked" from a stale MCP process (RAISE-15605) — fixed in rc1¶
Was: Every write operation failed with database is locked (SQLITE_BUSY)
when a long-lived MCP server process held an abandoned write transaction.
Fix: The SQLite WAL + busy-timeout fix landed in rc1. If you are still on a beta binary, upgrade via the installation guide. If after upgrading you still see this error, it means a pre-fix MCP process is still running — terminate it with SIGTERM and retry:
rai init --force destroyed cartridge content (RAISE-15655) — fixed in rc2¶
Was: --force cleared cartridge directories before copying, permanently
deleting hand-curated corpus/, eval/, and extractors/ without a backup.
Fix: --force now overwrites only what the bundle owns and leaves
everything else in place.
Windows: bare rai crashed on startup (RAISE-15650) — fixed in b2¶
Was: The cockpit imported the Unix-only termios and tty at module
scope; the command died with ModuleNotFoundError before printing anything.
Fix: The import is now guarded; Windows gets the available commands instead.
Windows: rai gate check crashed on startup (RAISE-15653)¶
Was: The worker-budget ledger imported the Unix-only fcntl at module
scope.
Fix: The locking backend is now selected at runtime (msvcrt on Windows).
rai self-update destroyed the local install (RAISE-16741)¶
Was: rai self-update derived the MCP install directory from the symlink's
own path instead of resolving it, so it replaced the shared ~/.local/bin and
destroyed every binary and symlink in it — its backup included.
Fix: shipped in 3.1.0. The symlink is now resolved, and an entry point that is not a symlink aborts with a clear error instead of proceeding.
Still live on every release candidate up to rc5
The fix is in 3.1.0 — not in the binary you are upgrading from. Do not run
rai self-update on rc1 through rc5; use the installer, per
route B.
Upgrading from an earlier version? See Upgrading to RaiSE 3.1.0.