Save/init ignore SQL execution errors, causing silent data-loss on failure

[kavix]

Description

cmd/init.go and cmd/save.go both call database.Exec(...) and discard
the returned error:

// init.go
database.Exec(`CREATE TABLE IF NOT EXISTS snapshots (...)`)

// save.go
database.Exec(
	"INSERT INTO snapshots(id, message, path) VALUES (?, ?, ?)",
	id, saveMessage, path,
)
fmt.Println("Snapshot saved:", id)

If the INSERT fails for any reason (locked DB, disk full, schema issue),
save.go still prints Snapshot saved: <id> — the user believes the
snapshot is recorded, but eko history / eko restore will never find it,
even though the file tree under .eko/snapshots/<id>/ was actually written.

Suggested fix

Check the error from every Exec call and surface it:

if _, err := database.Exec(...); err != nil {
	return fmt.Errorf("failed to record snapshot: %w", err)
}

[vsolano9]

This looks fixed on main — I think the issue can be closed, though there is one leftover below that may be worth its own issue.

The save.go half was fixed in 12c2de6 ("fix(cmd): add missing defer db.Close(), fix uncheked errors", 2026-07-28, @lastochkin-maks), which applied exactly the suggested fix:

if _, err := database.Exec(
    "INSERT INTO snapshots(...) VALUES (?, ?, ?, ?)", ...
); err != nil {
    return fmt.Errorf("failed to save snapshot to db: %w", err)
}

The init.go half went a different route and is also covered: init no longer runs CREATE TABLE inline. It calls db.MigrateDB(database) and checks the result (error initializing database schema: %w), and MigrateDB returns the CREATE TABLE error. That landed with 332af44.

Verified by reproducing the original failure

Rather than just read the diff, I forced the INSERT to fail the way the issue describes — built main at c0ae389, made the database read-only to simulate the locked/unwritable case, and ran a save:

$ chmod 444 .eko/db.sqlite
$ eko save -m "must not print success"
Error: failed to save snapshot to db: attempt to write a readonly database
$ echo $?
1

No Snapshot saved: line, non-zero exit, and eko history does not list it. The specific harm in the title — user believes it is recorded, history/restore never find it — no longer happens.

One thing the fix does not cover

The other half of the issue's description still holds: "the file tree under .eko/snapshots/<id>/ was actually written." The snapshot directory is created before the DB row, so a failed INSERT leaves it orphaned:

$ ls .eko/snapshots/
d29609a3          <- 20K, 4 files, written by the save that failed
$ eko restore d29609a3
Error: snapshot not found: sql: no rows in result set   (exit 1)

So the failure is now loud, but it leaks disk that nothing can reach or clean up — every retry against a still-unwritable DB adds another. It is a much smaller problem than silent data loss and clearly out of scope for this issue's title; flagging it in case you want a separate one for cleaning up the directory when the insert fails (or writing the row first).

For completeness, the two remaining unchecked calls both look deliberate rather than missed, so I did not touch them: db.go's _, _ = database.Exec("ALTER TABLE snapshots ADD COLUMN summary TEXT") is the idempotent add-column idiom that errors with "duplicate column name" on every run after the first, and save.go's _ = database.QueryRow(...).Scan(&prevPath) treats "no previous snapshot" as a normal state.

No PR from me here since there is nothing left to change for the titled bug.