fix(l2): rollup store SQLite migration for v9 to v10 upgrade

[avilagaston9]

Motivation

When upgrading an ethrex L2 from v9 to v10, the v10 binary panics on startup with:

Failed to create StoreRollup: SQLQueryError(SqliteFailure(1, "table latest_sent has 2 columns but 3 values were supplied"))

Description

v10 added a verified_at column to the latest_sent table. The DB_SCHEMA array runs as a single transaction during init_db(). On an existing v9 database, CREATE TABLE IF NOT EXISTS is a no-op (table already exists with 2 columns), but INSERT INTO latest_sent VALUES (0, 0, 0) fails because it supplies 3 values for a 2-column table. This rolls back the entire schema transaction, so the ALTER TABLE migration that adds the column never executes.

The fix uses explicit column names in the INSERT: INSERT INTO latest_sent (_id, batch) VALUES (0, 0). This works on both the old 2-column table and the new 3-column table (verified_at gets its DEFAULT 0).

How to Test

1. Start an L2 with v9, let it commit a few batches
2. Stop the L2, upgrade to v10
3. Start v10 — should no longer panic on latest_sent

[greptile-apps]

Greptile encountered an error while reviewing this PR. Please reach out to support@greptile.com for assistance.

[github-actions]

🤖 Kimi Code Review

crates/l2/storage/src/store_db/sql.rs

This change follows SQL best practices by explicitly specifying column names rather than relying on positional ordering. This makes the schema initialization more robust against future column additions or reorderings.

The behavior is functionally equivalent since verified_at has a DEFAULT 0 constraint (line 49), but the explicit column list is more maintainable.

No issues found. This is a correct code quality improvement.

---

Automated review by Kimi (Moonshot AI) · kimi-k2.5 · custom prompt

[Copilot]

Pull request overview

Fixes an L2 rollup store SQLite migration issue encountered when upgrading an existing v9 database to a v10 binary by making the latest_sent seed insert compatible with both the old (2-column) and new (3-column) table layouts.

Changes:

• Update the latest_sent seed statement to use explicit column names ((_id, batch)) so it doesn’t fail on pre-migration schemas.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[github-actions]

🤖 Claude Code Review

Now I have the full context. Here is my review:

---

Code Review: fix(l2): rollup store SQLite migration for v9 to v10 upgrade

Overview

A one-line targeted fix for a startup panic when upgrading an L2 node from v9 to v10. The DB_SCHEMA array executes as a single transaction in init_db(). The old positional INSERT INTO latest_sent VALUES (0, 0, 0) failed on existing v9 databases (which still have only 2 columns at that point), rolling back the entire schema transaction and preventing the subsequent ALTER TABLE migration from ever running.

---

The Fix

crates/l2/storage/src/store_db/sql.rs:50

-- Before
INSERT INTO latest_sent VALUES (0, 0, 0) ON CONFLICT(_id) DO NOTHING
-- After
INSERT INTO latest_sent (_id, batch) VALUES (0, 0) ON CONFLICT(_id) DO NOTHING

This is correct and minimal. Using explicit column names ensures the statement is valid against both the old 2-column schema and the new 3-column schema — verified_at gets its DEFAULT 0 on fresh installs, and the ALTER TABLE (which runs outside the transaction with its error intentionally ignored) handles the upgrade path.

All three cases are covered:

• Fresh v10 install: 3-column table created, INSERT omits verified_at → uses DEFAULT 0. ALTER TABLE fails silently (column exists). ✓
• v9→v10 upgrade: CREATE TABLE IF NOT EXISTS is a no-op, INSERT now works on the 2-column table, then ALTER TABLE successfully adds verified_at. ✓
• v10 restart: ON CONFLICT(_id) DO NOTHING prevents a duplicate row. ✓

---

Observations and Concerns

Two other tables have the same latent risk.

Lines 48 and 57 use the same positional VALUES pattern:

-- line 48
INSERT INTO operation_count VALUES (0, 0, 0, 0) ON CONFLICT(_id) DO NOTHING
-- line 57
INSERT INTO latest_sent_to_aligned VALUES (0, 0, 0) ON CONFLICT(_id) DO NOTHING

If either of these tables gains a column in a future version, the same startup panic will recur. Applying explicit column names consistently to all three singleton-row tables (operation_count, latest_sent, latest_sent_to_aligned) would eliminate the class of bug entirely. This isn't blocking for this PR since those tables haven't changed, but it is worth a follow-up.

Silent error handling in init_db() (lines 112–117) is intentional but opaque.

let _ = self
    .execute("ALTER TABLE latest_sent ADD COLUMN verified_at INT DEFAULT 0", ())
    .await;

The let _ discard is the right choice here — it handles both "column already exists" (fresh install) and "column added" (upgrade) in one shot. However, it would also silently swallow real errors (disk full, permission issues, SQL typos). A tighter approach would be to check the error kind and only ignore SqliteFailure with code 1 (SQLITE_ERROR, i.e. "duplicate column name"). That said, given the simplicity of the statement and that a subsequent read of verified_at would fail loudly anyway, this is a low-priority concern.

No automated migration test.

The upgrade path (v9 schema → v10 binary) is exercised only by the manual steps in the PR description. A test that spins up an in-memory SQLite with the old 2-column latest_sent, then calls SQLStore::new / init_db, and asserts that verified_at is present and readable would catch regressions here and provide documentation of the migration invariant. Worth adding, but not a blocker.

---

Summary

The fix is correct, surgically minimal, and clearly explained. The root cause is accurately diagnosed. No new issues are introduced. The main actionable takeaways are:

• Consider updating operation_count and latest_sent_to_aligned INSERTs to use explicit column names as a proactive follow-up.
• Consider a migration integration test.

Verdict: Approve with the above as optional follow-up items.

---

Automated review by Claude (Anthropic) · sonnet · custom prompt

[github-actions]

🤖 Codex Code Review

No findings.

The change in sql.rs looks correct: inserting only (_id, batch) lets SQLite apply the verified_at INT DEFAULT 0 default on fresh databases, while remaining compatible with older databases that still had the pre-migration two-column latest_sent table before the later ALTER TABLE at sql.rs. That preserves the verified_at > 0 timeout guard behavior used by the proof sender at l1_proof_sender.rs.

I verified the SQL behavior directly with sqlite3 for both fresh-schema and old-schema-then-migrate cases; both produce the expected sentinel row (0, 0, 0). I could not run cargo test in this environment because rustup cannot create temp files on the read-only filesystem.

---

Automated review by OpenAI Codex · gpt-5.4 · custom prompt