feat(cli): add assistant db status for read-only DB inspection#32606
Merged
Conversation
First subcommand under a new `assistant db` group dedicated to inspecting and (in follow-ups) repairing the assistant SQLite database. Designed for recovery / triage: opens the DB file directly via bun:sqlite in read-only mode and never goes through the daemon — the surface needs to work precisely when the database is broken and the daemon won't start. Reports: - file path, sizes (.db / .db-wal / .db-shm), owner uid/gid + mode (the latter catches UID-isolation regressions on shared volumes) - SQLite version and key pragmas (journal_mode, synchronous, page_size, wal_autocheckpoint, mmap_size) - total table count + 5 largest tables — by `dbstat` bytes when the runtime SQLite has it compiled in, otherwise by row count. Bun's bundled SQLite omits dbstat, so the row-count path is what most users hit today; we detect at runtime via a try/catch rather than parsing PRAGMA compile_options strings (which has historically drifted across versions) - latest applied migration, read from `memory_checkpoints` rows that the workspace migration runner writes with value='1' on success - file mtime + age, for 'is this DB live?' triage If the DB is missing, exits 1 with a loud error pointing the user at `assistant backup list` and (preview of PR 3) the conversation disk-view recovery path. Naming note: cli-design.md says `get` over `status` as a convention, but I'm shipping under `status` per the recovery-plan ask. Happy to rename in a follow-up if we want to enforce the convention here too. Wired up: - new directory: `assistant/src/cli/commands/db/` with `index.ts`, `status.ts`, `format.ts`, and tests - transport: `local` — no daemon roundtrip, no IPC - registered in `program.ts` alphabetically between `credentials` and the email-gated commands - added `db` and `db status` to the gateway risk-registry supported-paths list (no override needed — read-only defaults to the low-risk baseline) Tested: - 7 unit tests covering happy path, missing-DB error, --json shape, the 'started' vs '1' migration filter, and the no-memory_checkpoints-table fallback - smoke-tested against the live workspace database Refs: recovery + monitoring workstream
vellum-apollo-bot
Bot
force-pushed
the
apollo/assistant-db-status
branch
from
bdb947d to
9d1f33f
Compare
dvargasfuertes
approved these changes
May 29, 2026
| name: "db", | ||
| transport: "local", | ||
| description: | ||
| "Inspect and repair the assistant SQLite database (read-only by default)", |
Contributor
There was a problem hiding this comment.
Suggested change
| "Inspect and repair the assistant SQLite database (read-only by default)", | |
| "Inspect and repair the assistant SQLite database", |
it's not read only by default?
This was referenced May 29, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Follow-up to #32583 addressing both Codex review comments. One was a legitimate bug; the other was a misread of React reconciliation, locked in as a regression test instead.
Codex P2 #1 — Legitimate bug, fixed
The merged code applied
style={{ minHeight: viewportMinHeight }}to the latest-edge wrapper wheneverrenderAvatarwas present — even withpartition.anchorMessage === null(assistant-only history: recovered conversations whose user message was lost, onboarding before the first submit).useViewportMinHeightreports the scroll container'sclientHeight≈ a full viewport.refactor(web): scroll to bottom on transcript container DOM attach (#32239)snaps the scroll to bottom on conversation switch. With no anchor at the top of the spacer, the bottom-pinned viewport lands on blank space + the avatar — the actual latest assistant message sits one viewport above and is invisible until the user scrolls up.Fix: gate both
minHeight: viewportMinHeightand theflex-1spacer onpartition.anchorMessage. Without an anchor, the avatar renders inline directly below the last history item.Codex P2 #2 — Misread, locked in as a regression test
Empirically verified that this does not happen. React's
reconcileChildrenArraytracksfiber.index(the previous render's position in the children array, includingfalse-skipped slots). When slot 0 transitions fromfalseto<LatestTurnRow>, the existing avatar fiber atfiber.index=2still matchesnewIdx=2in the next render — same<div>type, fiber reused,ChatAvataris not unmounted.Locked in with a DOM-lifecycle regression test that:
mount=1, unmount=0.mount=1, unmount=0(no remount).mount=1, unmount=0again.A sanity check (forcing a
conversationIdchange, which re-keys the scroll container) was used to confirm the mount tracker actually detects remounts when they happen (mount=2, unmount=1). The test framework can fail; the assertions are real.Tests
transcript.test.tsxtests pass.min-height; anchor wrapper hasmin-height; anchor-without-avatar still hasmin-height(regression guard for the original viewport-pinning behavior).tsc --noEmit --skipLibCheckinapps/web).transcript-message-body.test.tsxfailures in the directory-wide run reproduce onmaintoo — caused by mock bleed between test files, not by this PR.Why this is a follow-up rather than amending the original
#32583 was already merged before Codex's review surfaced. Per the SE-skill
pr-lifecycle.mdrule on bot reviewers being real reviewers, every comment gets a response — either an iteration or a rationale. This PR is both: iterates on #1, rationalizes #2 with empirical evidence.