Two latent bugs in FlowRepositorySqlite, discovered while writing the test seed for the be-1595-flight-execution-id-parity-2026-06-17 work. Local Sqlite dev/test path only — these do NOT affect Postgres prod. Worth a separate ticket.
For Agents
Both bugs live in
mando-lib/src/workflow/repository/flow_repository_sqlite.rsand only bite the SQLite-backed dev/test repository. Postgres prod uses a different impl and is unaffected. They were latent (test-seed only exercises this path), not user-facing regressions.
Bug 1 — create_flow may never persist the row
FlowRepositorySqlite::create_flow (flow_repository_sqlite.rs:111) uses lazy stmt.query(params![...]) for an INSERT and then drops the Rows without iterating.
rusqlite footgun
Statement::queryreturns a lazyRowsiterator; for a statement with no result rows the SQL may never execute unless you step the iterator. Dropping theRowswithout iterating means the INSERT can be silently skipped — the row never persists.
Fix: use .execute() (or .insert()) for an INSERT, not .query().
Bug 2 — started_at TEXT default unreadable as i64
The flow_execution.started_at schema default is current_timestamp, which stores a TEXT value. But get_execution reads column 2 as an i64 (Utc.timestamp_micros(...)).
Schema default vs. read type mismatch
A
flow_executionrow created without an explicit integerstarted_at(i.e. relying on thecurrent_timestampdefault) cannot be read back: rusqlite raisesInvalidColumnType(TEXT vs i64).
Fix options: either store started_at as integer micros on insert (don’t rely on the current_timestamp TEXT default), or change the schema default / read code so the stored type and the read type agree.