fix(server): migration 050 no longer stalls startup on large databases - #234
Merged
Conversation
Nightly .274/.275 (PR #221) added migration 050, which backfills an event_sequence column with a correlated subquery over a CTE. SQLite plans that as a co-routine that re-scans the entire orchestration_events table for every projected row. On a 3.2 GB database (~487k events, ~222k activities) the first of three backfills did not finish in four minutes, the desktop's 60-second readiness timer killed the backend, the transaction rolled back, and every "Try Again" repeated the same work. Rewrite the three backfills as UPDATE ... FROM so the first-event lookup is materialized once and joined. Same result; both new migrations run in about eight seconds on the same database. Add a guideline line asking for migrations that rewrite rows to be timed against real history.
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
github-actions
Bot
added
vouch:trusted
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Updating to nightly .274 or .275 on a database with real history left the desktop app stuck at "Threadlines couldn't start". The backend printed "Running all migrations..." and never answered, the 60-second readiness timer killed it, and Try Again repeated the same work.
The cause is migration 050 from #221. Its backfills use a correlated subquery over a CTE, which SQLite executes as a co-routine that re-scans the whole
orchestration_eventstable for every projected row. On a 3.2 GB database (about 487k events and 222k activity rows) the first backfill alone ran past four minutes. Because each migration runs in a transaction, the kill rolled everything back and the database stayed at migration 49, so no data was harmed.The fix rewrites the three backfills as
UPDATE ... FROM (subquery), so the first-event lookup is built once and joined. Same result, different plan. Running the real migrator against a copy of that same database now completes migrations 050 and 051 in about eight seconds. The existing migration test still passes, and the repo guidelines gain one line asking for row-rewriting migrations to be timed against real history before merge.Follow-up, separate PR: the desktop should recognize a backend that is still migrating instead of killing it after 60 seconds, and the migrator should log each migration's duration.