Flaky timing assertion in test_sync_timeout_spans_multiple_levels_elapsed_time

[coderabbitai]

Summary

The test test_sync_timeout_spans_multiple_levels_elapsed_time in tests/resolution/test_timeout_sync.py (lines 205–206) contains a tight upper-bound timing assertion that may cause flaky failures in CI environments.

Details

The assertion checks that elapsed time is within ±10% of the timeout value:

assert elapsed >= timeout * 0.9, f"Timed out too early: {elapsed:.3f}s < {timeout * 0.9:.3f}s"
assert elapsed < timeout * 1.1, f"Timed out too late: {elapsed:.3f}s > {timeout * 1.1:.3f}s"

With a timeout = 0.4s, the upper bound is only 0.44s — a margin of just 40ms. Under CI load, scheduling jitter or GC pauses can easily exceed this margin, making this test intermittently fail.

Suggested Fix

Widen the upper bound tolerance while keeping the lower bound tight, for example:

assert elapsed >= timeout * 0.9, f"Timed out too early: {elapsed:.3f}s < {timeout * 0.9:.3f}s"
assert elapsed < timeout * 2.0, f"Timed out too late: {elapsed:.3f}s > {timeout * 2.0:.3f}s"

This ensures the test still validates that the timeout deadline carries across unpacking levels (rather than restarting per level), while being resilient to CI scheduling jitter.

References

• PR: More robust PromisingContext hierarchy tracking and awaiting #93
• Comment: More robust PromisingContext hierarchy tracking and awaiting #93 (comment)
• Reported by: @teremterem