You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
tests-windows pins one Python version, so clock-resolution bugs are invisible on Windows for 3 of 5 supported versions #4472
tests-windows pins a single Python version, so a whole class of bug is invisible to CI on the one platform where it occurs. #4392 was an instance of that class; this is about the gap that let it sit there.
The gap
tests (matrix) ubuntu-latest 3.10 3.11 3.12 3.13 3.14
tests-windows windows-latest 3.13 only
packaged-contract-windows 3.13 only
The project's classifiers claim 3.10 through 3.14, and the Linux matrix honours that. On Windows only one version is exercised, and it happens to be the version where the failure in #4392 does not reproduce.
Why that particular version hides things
From the measurements in #4392, datetime.now() resolution on Windows over a 1000-call burst:
Python
distinct timestamps per 1000 calls
3.10.19
2
3.11.14
2
3.12.12
2
3.13.11
1000
3.13 is the version where the Windows clock stopped being coarse. Pinning Windows CI to exactly that version means anything sensitive to clock granularity, ordering on tied timestamps, or short-interval timing is untested on Windows for three of the five supported versions. In #4392 that was 37 tests failing on a clean checkout while CI stayed green.
To be clear about scope: #4392 fixed the instance, so nothing is failing right now as far as I know. This is about the next one.
Suggestion, sized for the CI bill
Windows runners bill at a higher multiplier, so a full five-version Windows matrix is probably not worth it. Adding one older version would cover the class:
3.10 is the declared minimum and sits on the coarse-clock side; 3.13 is what runs today. That is 2x the current Windows cost rather than 5x, and it would have caught #4392 before it reached a contributor's machine.
If even that is too much, running the older version on a schedule rather than per-PR would still surface the class, just later.
I am happy to send the PR if you tell me which shape you want, or to leave it if the cost is not worth the coverage. Filing this rather than opening a PR straight away because the CI budget is your call, not mine.
Thanks for taking this straight to a PR, and for going wider than I asked. Checked #4475 on the specific gap: tests-windows now carries a matrix with 3.10 alongside 3.13, so the coarse-clock side of the split is covered on the platform where it matters. That closes the class #4392 came from.
The 3.13-not-3.14 note in the matrix is the part I could not have known:
Keep Python 3.13 here because Daytona's locked obstore dependency has no Windows Python 3.14 wheel, so 3.14 builds it from source and exceeds this job's timeout.
Good to have that written down next to the pin rather than rediscovered the next time someone tries to bump it.
Nothing further from me. @feiiiiii5 sorry your PR got overtaken.
Activity
seratch commentedon Aug 17, 2026
This makes sense. Could you send a PR for it?
ErenAta16 commentedon Aug 17, 2026
Thanks for taking this straight to a PR, and for going wider than I asked. Checked
#4475on the specific gap:tests-windowsnow carries a matrix with 3.10 alongside 3.13, so the coarse-clock side of the split is covered on the platform where it matters. That closes the class #4392 came from.The 3.13-not-3.14 note in the matrix is the part I could not have known:
Good to have that written down next to the pin rather than rediscovered the next time someone tries to bump it.
Nothing further from me. @feiiiiii5 sorry your PR got overtaken.