warp apply: SQLite layer hard-fails on uninitialized/empty DB and targets the wrong Warp channel #128

New issue

Closed

opened 2026-06-02 07:01:45 +00:00 by coilysiren · 2 comments

coilysiren commented

2026-06-02 07:01:45 +00:00

Owner

Symptom

coily exec warp apply (now invoked by setup.sh) writes the template layers fine, then exits 1 at the SQLite layer:

  settings.toml          WROTE ...
  theme yaml             ok    ...
  startup_config.toml    WROTE ...
error: querying generic_string_objects: SQL logic error: no such table: generic_string_objects (1)

Root cause

Two distinct defects in the warp tool.

1. The SQLite layer hard-fails on an uninitialized DB. openWarpDB (warp/sqlite.go) opens the target warp.sqlite and only the db.Ping() failure routes to the SKIP path at warp/main.go:96. A 0-byte file is a valid empty SQLite DB, so Ping passes. The loop then calls db.get(), which runs SELECT id, data FROM generic_string_objects against a DB that has no tables, and warp/main.go:112-114 does return err, propagating out of applySQLite -> runApply and exiting non-zero. doctorSQLite (warp/main.go:176) hits the same path. An uninitialized DB (Warp installed but not yet launched, or the wrong channel) is a normal state and should SKIP, consistent with the doctor's stated "SQLite drifts as normal steady-state behavior" stance.

2. Channel mismatch: the tool targets Stable, Kai runs Preview. warp/paths.go:62-65 hardcodes the Stable bundle DB path with the comment "Kai runs Preview; Stable bundle id is the best default." Evidence on kais-macbook-pro:

~/Library/Application Support/dev.warp.Warp-Stable/warp.sqlite exists but is 0 bytes (mtime 2026-05-28), so it has no generic_string_objects table.
~/Library/Application Support/dev.warp.Warp-Preview/warp.sqlite is absent.

So the layer points at an empty Stable stub while the actual daily-driver Preview DB is not at the probed path. The render layers that carry the real config (settings.toml, theme, startup_config.toml) still apply, so this is a SQLite-layer-only failure.

Proposed fix

Make missing-table a SKIP. In applySQLite and doctorSQLite, detect the "no such table: generic_string_objects" case (or check table existence up front via sqlite_master) and SKIP with a notice instead of returning the error. An empty/0-byte DB should also SKIP.
Resolve the channel that is actually initialized. On darwin, probe the Preview bundle path as well (Preview is the documented daily driver per warp/README.md) and prefer whichever warp.sqlite exists and is non-empty, rather than hardcoding Stable.

Workaround until fixed

The setup.sh auto-run already degrades gracefully (the || echo guard catches the non-zero exit and setup still completes). The config-bearing template layers apply regardless.

Found while verifying the setup.sh warp auto-run end to end (follow-up to #126, #127).

## Symptom `coily exec warp apply` (now invoked by `setup.sh`) writes the template layers fine, then exits 1 at the SQLite layer: ``` settings.toml WROTE ... theme yaml ok ... startup_config.toml WROTE ... error: querying generic_string_objects: SQL logic error: no such table: generic_string_objects (1) ``` ## Root cause Two distinct defects in the warp tool. **1. The SQLite layer hard-fails on an uninitialized DB.** `openWarpDB` (`warp/sqlite.go`) opens the target `warp.sqlite` and only the `db.Ping()` failure routes to the SKIP path at `warp/main.go:96`. A 0-byte file is a valid *empty* SQLite DB, so Ping passes. The loop then calls `db.get()`, which runs `SELECT id, data FROM generic_string_objects` against a DB that has no tables, and `warp/main.go:112-114` does `return err`, propagating out of `applySQLite` -> `runApply` and exiting non-zero. `doctorSQLite` (`warp/main.go:176`) hits the same path. An uninitialized DB (Warp installed but not yet launched, or the wrong channel) is a normal state and should SKIP, consistent with the doctor's stated "SQLite drifts as normal steady-state behavior" stance. **2. Channel mismatch: the tool targets Stable, Kai runs Preview.** `warp/paths.go:62-65` hardcodes the Stable bundle DB path with the comment "Kai runs Preview; Stable bundle id is the best default." Evidence on kais-macbook-pro: - `~/Library/Application Support/dev.warp.Warp-Stable/warp.sqlite` exists but is **0 bytes** (mtime 2026-05-28), so it has no `generic_string_objects` table. - `~/Library/Application Support/dev.warp.Warp-Preview/warp.sqlite` is **absent**. So the layer points at an empty Stable stub while the actual daily-driver Preview DB is not at the probed path. The render layers that carry the real config (settings.toml, theme, startup_config.toml) still apply, so this is a SQLite-layer-only failure. ## Proposed fix - **Make missing-table a SKIP.** In `applySQLite` and `doctorSQLite`, detect the "no such table: generic_string_objects" case (or check table existence up front via `sqlite_master`) and SKIP with a notice instead of returning the error. An empty/0-byte DB should also SKIP. - **Resolve the channel that is actually initialized.** On darwin, probe the Preview bundle path as well (Preview is the documented daily driver per `warp/README.md`) and prefer whichever `warp.sqlite` exists and is non-empty, rather than hardcoding Stable. ## Workaround until fixed The `setup.sh` auto-run already degrades gracefully (the `|| echo` guard catches the non-zero exit and setup still completes). The config-bearing template layers apply regardless. Found while verifying the `setup.sh` warp auto-run end to end (follow-up to #126, #127).

coilysiren commented

2026-06-02 07:05:52 +00:00

Author

Owner

Clarification from Kai on the channel fix (defect 2)

The per-OS channel mapping is deterministic, not "probe both":

macOS - Kai runs Warp Preview only. So darwin should target the Preview bundle path (dev.warp.Warp-Preview/warp.sqlite), not Stable. The current Stable hardcode is simply wrong for Mac.
Windows - Kai runs Warp Stable (there is no Warp Preview on Windows). The existing Windows path (%LOCALAPPDATA%/warp/Warp/data/warp.sqlite) stays as-is.
Linux - unchanged.

So defect 2 is a one-line darwin retarget (Stable -> Preview), not a dual-channel probe.

Defect 1 (SKIP on uninitialized/missing-table DB) is still required independently: on this host Preview's warp.sqlite was absent, so even after retargeting, an empty/auto-created DB must SKIP rather than hard-fail.

## Clarification from Kai on the channel fix (defect 2) The per-OS channel mapping is deterministic, not "probe both": - **macOS** - Kai runs **Warp Preview only**. So darwin should target the Preview bundle path (`dev.warp.Warp-Preview/warp.sqlite`), not Stable. The current Stable hardcode is simply wrong for Mac. - **Windows** - Kai runs **Warp Stable** (there is no Warp Preview on Windows). The existing Windows path (`%LOCALAPPDATA%/warp/Warp/data/warp.sqlite`) stays as-is. - **Linux** - unchanged. So defect 2 is a one-line darwin retarget (Stable -> Preview), not a dual-channel probe. Defect 1 (SKIP on uninitialized/missing-table DB) is still required independently: on this host Preview's `warp.sqlite` was absent, so even after retargeting, an empty/auto-created DB must SKIP rather than hard-fail.

coilysiren commented

2026-06-02 07:07:11 +00:00

Author

Owner

Correction to the previous comment

The prior comment said "there is no Warp Preview on Windows." That is factually wrong - Warp's own docs state Preview ships on all platforms (macOS, Windows, Linux). The per-OS channel mapping for the fix still stands, but the rationale is "what Kai runs," not platform availability:

macOS -> Preview (what Kai runs).
Windows -> Stable (what Kai runs, even though Preview exists there too).
Linux -> unchanged.

Source: https://docs.warp.dev/getting-started/quickstart/installation-and-setup/

Extra reason defect 1 matters

Warp (Stable and Preview) auto-updates itself - it checks releases.warp.dev on startup and periodically and self-replaces. So the targeted DB's SQLite schema can change under the warp tool at any time without a brew step. That makes the "SKIP on unexpected/missing schema" behavior (defect 1) the correct robustness posture, not just a fix for the empty-DB case.

## Correction to the previous comment The prior comment said "there is no Warp Preview on Windows." That is **factually wrong** - Warp's own docs state Preview ships on all platforms (macOS, Windows, Linux). The per-OS channel mapping for the fix still stands, but the rationale is "what Kai runs," not platform availability: - **macOS** -> Preview (what Kai runs). - **Windows** -> Stable (what Kai runs, even though Preview exists there too). - **Linux** -> unchanged. Source: https://docs.warp.dev/getting-started/quickstart/installation-and-setup/ ## Extra reason defect 1 matters Warp (Stable and Preview) **auto-updates itself** - it checks `releases.warp.dev` on startup and periodically and self-replaces. So the targeted DB's SQLite schema can change under the warp tool at any time without a brew step. That makes the "SKIP on unexpected/missing schema" behavior (defect 1) the correct robustness posture, not just a fix for the empty-DB case.

coilysiren referenced this issue from a commit

2026-06-02 07:10:54 +00:00

fix(warp): skip SQLite layer on uninitialized DB and target Preview on macOS

coilysiren closed this issue

2026-06-02 07:10:54 +00:00