Skip to content

Fix flaky scheduler test#5030

Open
krMaynard wants to merge 2 commits into
ankitects:mainfrom
krMaynard:fix-flaky-scheduler-test
Open

Fix flaky scheduler test#5030
krMaynard wants to merge 2 commits into
ankitects:mainfrom
krMaynard:fix-flaky-scheduler-test

Conversation

@krMaynard

Copy link
Copy Markdown

Linked issue (required)

Fixes #5025

Summary / motivation (required)

scheduler::answering::test::new_limited_by_reviews in
rslib/src/scheduler/answering/mod.rs is time-of-day dependent and fails when
run between roughly 3:50–4:00 GMT. The source carried a
// FIXME: This fails between 3:50-4:00 GMT comment documenting the flakiness.

The test's final answer_good() schedules a learning card a 10-minute step
ahead. Run shortly before the default 4am rollover, that step crosses into the
next day, so the card is no longer counted as intraday learning and the final
assert_counts!(col, 0, 0, 0) breaks.

This guards the test with the same if col.timing_today()?.near_cutoff() { return Ok(()); }
early-return that the sibling timing-sensitive tests in this file
(state_application, elapsed_secs) already use, and replaces the FIXME with a
comment explaining the cause. near_cutoff()'s 25-minute margin safely covers
the 10-minute step window.

Steps to reproduce (required, use N/A if not applicable)

  1. Set the system clock to a few minutes before the collection's daily cutoff
    (the default 4am rollover — i.e. ~03:50–03:59 in the collection's timezone).
  2. Run cargo test -p anki --lib scheduler::answering::test::new_limited_by_reviews.
  3. The final assert_counts!(col, 0, 0, 0) fails because the last learning
    card's 10-minute step lands after the cutoff.

How to test (required)

Checklist (minimum)

  • I ran ./ninja check or an equivalent relevant check locally.
  • I added or updated tests when the change is non-trivial or behavior changed.

Details

cargo test -p anki --lib scheduler::answering::test::new_limited_by_reviews
passes, and the full scheduler::answering module passes (5/5). The fix mirrors
the existing near_cutoff() guard already used by the two sibling
timing-sensitive tests in the same file.

Before / after behavior (optional)

Before: the test fails non-deterministically in the ~10-minute window before the
daily cutoff. After: it early-returns in the near-cutoff window (25-minute
margin) and runs normally the rest of the day.

Risk / compatibility / migration (optional)

N/A — test-only change, no production behavior affected.

UI evidence (required for visual changes; otherwise N/A)

N/A

Scope

  • This PR is focused on one change (no unrelated edits).

The test's final answer schedules a learning card a 10-minute step ahead.
When run shortly before the daily cutoff (3:50-4:00 GMT with the default
4am rollover), that step crosses into the next day, so the card is no
longer counted as intraday learning and the expected queue counts break.

Guard the test with the same near_cutoff() early-return that the sibling
timing-sensitive tests (state_application, elapsed_secs) already use, and
replace the FIXME with an explanation of the cause.
@read-the-docs-community

Copy link
Copy Markdown

Documentation build overview

📚 Anki | 🛠️ Build #33175226 | 📁 Comparing 446e859 against latest (0d7b3fd)

  🔍 Preview build  

5 files changed · ± 5 modified

± Modified

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Flaky test: new_limited_by_reviews fails near the daily cutoff

1 participant