fix(migrate): emit progress line before first tick - #1478
Conversation
|
This change is part of the following stack: Change managed by git-spice. |
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
Included review availability: 4 reviews are currently available. Your included PR review attempts over the past 7 days set your current allowance at 5 reviews per hour. 📝 WalkthroughSummary by CodeRabbit
WalkthroughThe migration progress logic now uses a reusable ChangesMigration progress reporting
Estimated code review effort: 2 (Simple) | ~10 minutes Merge Risk: ⚪ Minimal · up to The change emits progress immediately for non-empty migrations while preserving empty-run behavior, with no actionable merge-blocking risk remaining after normal checks and review. Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches📝 Generate docstrings
Comment |
The chunks-to-nar progress reporter was driven purely by a ticker, so a migration that finished inside a single interval emitted no progress line at all -- the ticker simply never fired. That is a real reporting gap for short migrations, and it made TestMigrateChunksToNar_CLI_ProgressLogEmitted non-deterministic: with the interval overridden to 1ms and a one-item migration, the work raced the first tick and lost roughly four runs in five (verified on a clean tree with unrelated changes stashed). Extract the emission into a logProgress closure and call it once up front when there is work to do, then once per tick as before. The immediate call makes at least one progress line guaranteed whenever total > 0, which removes the race, and gives operators feedback instead of a silent first interval. The call is gated on total > 0 so an empty run stays completely silent, preserving TestMigrateChunksToNar_CLI_NoProgressLogOnEmptyRun. Verified: 12/12 consecutive runs of both progress tests pass. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_014zzHofsGpUn34b21AeP3yP
88e3be2 to
ef5be3b
Compare
Summary
The chunks-to-nar progress reporter was driven purely by a ticker, so a migration
that finished inside a single interval emitted no progress line at all — the ticker
never fired.
That is a real reporting gap for short migrations, and it made
TestMigrateChunksToNar_CLI_ProgressLogEmittednon-deterministic. With the intervaloverridden to 1ms and a one-item migration, the work raced the first tick and lost
roughly four runs in five. Verified on a clean tree with unrelated changes
stashed, so this is pre-existing on
mainand not caused by anything stacked above it.Approach
Extract the emission into a
logProgressclosure and call it once up front when thereis work to do, then once per tick as before.
total > 0, which removes the race.total > 0so an empty run stays completely silent, preservingTestMigrateChunksToNar_CLI_NoProgressLogOnEmptyRun.Test plan
task fmtexits 0task lintexits 0task testexits 0