Stabilize large-event migration regression - #2502
Merged
ymichael merged 1 commit intoAug 27, 2026
Merged
Conversation
ymichael
deleted the
bb/ci-flake-fix-db-inline-large-value-migration-5s-thr_pxhahjff5h
branch
August 27, 2026 16:28
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
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.
Human comments
What was wrong
The inline large-event migration regression constructed a current database with a full 100+ migration replay inside the case, rewound it to the legacy checkpoint, then ran the real forward migration under test. The first full migration was fixture setup rather than behavior under assertion, but it consumed the same 5 s test budget as the second migration. Stage measurements attributed 86% of the unloaded case and 83% under contention to those two full migrations, which made ordinary packages-shard CPU contention amplify the case past Vitest's unchanged ceiling in CI run 33006897846.
What changed
beforeAll, outside either case's timeout budget. Both cases still invoke the real productionmigrate()boundary after the rewind and retain their migration-ledger, removed-table, and inline-payload assertions.HOST_DAEMON_PROTOCOL_VERSIONis unchanged.How you verified
pnpm exec turbo run test --filter=@bb/db --force -- --reporter=verbose test/migrate.test.ts: 42/42 passed; 2.68 s file duration.pnpm exec turbo run test --filter=@bb/db --force: 409/409 passed; 28/28 files.pnpm exec turbo run typecheck --filter=@bb/db --force: passed.pnpm exec turbo run build --filter=@bb/db --force: passed; Turbo reported that@bb/dbdefines no build task.Tests (packages, ubuntu-latest, Node 22.x): passed; the exact case completed in 915 ms and the 42-case migration file in 26.764 s.