SQLite state file may be partially written after interrupted Reflex 0.5.0 migration

When upgrading a Reflex application from a version that used in‑memory state to Reflex 0.5.0, the framework expects a SQLite database at the location previously used for state storage. The supplied reflex migrate-state command copies the existing in‑memory state into this new file, but the operation is not wrapped in a transaction. If the migration is halted—by a power loss, process kill, or user interruption—the SQLite file can be left partially written or corrupted. On the next start, Reflex treats this as a fatal error and fails to launch, with no automatic rollback to the previous in‑memory state.

What mechanisms, if any, does Reflex provide to detect a partially written SQLite state file after an interrupted migration?

Should users rely solely on pre‑migration backups and integrity checks, or is there a preferred automated fallback strategy?

Is there a plan to make the migration command transactional or to introduce an automatic rollback mechanism in a future release?