test(tui): de-flake near-tail journal-jump scroll assertion#108
Conversation
The jump handler defers its scroll via a set_timer until the RichLog flushes its lines and grows tall enough to scroll. The test waited on a bare `is_vertical_scroll_end`, which is trivially true in the pre-flush empty state (scroll_y == max_scroll_y == 0), so on a fast capture it sampled anchored=0 before the deferred scroll landed at the tail. The delayed jump then moved the view to 188, tripping `assert 188 == 0`. Gate the wait on `max_scroll_y > 0 and is_vertical_scroll_end` so it samples only after the content is actually rendered at the tail - the tail-variant of the `0 < scroll_y < max_scroll_y` guard its sibling jump test already uses. Also add the flaky marker its two sibling journal-jump tests carry for the orthogonal poll-supersede stall. No product change; the anchor logic was already correct.
|
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)
WalkthroughThe journal jump test is marked flaky and now waits for the log pane to render scrollable content before checking that it is at the vertical end. ChangesJournal jump test
Estimated code review effort: 1 (Trivial) | ~3 minutes Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
What
De-flake
test_journal_jump_near_tail_does_not_chase_growing_log, which intermittently failed in CI withassert 188 == 0. Test-only change.Why
The jump handler (
_jump_to_log_event→_scroll_log_to) defers its scroll via aset_timeruntil theRichLogflushes its lines and grows tall enough to scroll. The test waited on a bareis_vertical_scroll_end, which is trivially true in the pre-flush empty state (scroll_y == max_scroll_y == 0). On a fast capture it sampledanchored = 0before the deferred scroll landed at the tail; the delayed jump then moved the view to 188, trippingassert 188 == 0.The
188was the legit jump landing (old content max), never tail-chasing — the product anchor (_log_follow_tail = False) was already correct. This is a test-synchronization race, not a product bug.How
max_scroll_y > 0 and is_vertical_scroll_endsoanchoredis sampled only after content is actually rendered at the tail. This is the tail-variant of the0 < scroll_y < max_scroll_yguard the siblingtest_journal_enter_jumps_to_log_positionalready uses.@pytest.mark.flaky(reruns=2, reruns_delay=1), matching the two sibling journal-jump tests, for the orthogonal exclusive-poll-supersede stall theuntildocstring documents.Testing
Ran the target 5× with flaky reruns disabled (
-p no:flaky) → 5/5 green, so the wait fix alone is deterministic; the marker is belt-and-suspenders. Ruff check + format clean. No other test in the suite uses the bare-scroll-end wait pattern.Summary by CodeRabbit