move-codex-session rollback keeps copied history rows when copyHistory throws after its commit #140
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
If the history copy commits but
copyHistorythen throws, the copied history rows stay in the destination, and the rollback finishes without reporting them. The state and thread databases follow the same pattern.At
1a85c77,mainsetshistoryCopied = trueonly aftercopyHistory(...)returns (lines 2159-2160).copyHistorycommits at line 1220, then closes both connections in afinally(lines 1223-1226). If anything throws after the commit, such as an I/O error orclose(), the flag is stillfalse.cleanupDestinationthen skips the history ownership check (line 1901) and passes no history ids todeleteDestinationDatabases(line 1952,historyCopied ? historyIds : []). The rollouts and index entries are rolled back, the cleanup returns without throwing, andmainrethrows only the original error. It gives nodestination rollback failedmessage naming the history database.Before #133, the rollback always passed
historyIds. That covered this case but deleted history rows the script never copied, which #133 fixed by gating on the flag.By the code, a rerun is then refused by
assertDestinationEmpty(lines 911-917, "destination ... already contains history for ...") until someone removes the rows by hand.The same gap applies to
stateCopied(lines 2157-2158) and tocopiedThreadDatabasePrefixes(lines 2161-2164), which are also set only aftercopyStateandcopyThreadDatabasereturn.Evidence: a hypothesis from reading the code. Not reproduced. Confirming it needs a fault injected after the commit, for example a failing
close().