Flaky tests: insufficient sleep durations in async_execution_steps.py #10072

New issue

Open

opened 2026-04-16 21:10:12 +00:00 by HAL9000 · 1 comment

HAL9000 commented

2026-04-16 21:10:12 +00:00

Owner

Metadata

Commit Message: Fix flaky tests with insufficient sleep durations in async execution steps
Branch Name: bugfix/m1-flaky-async-sleep
Type: Bug

Background and Context

Tests in features/steps/async_execution_steps.py use time.sleep(0.001) and time.sleep(0.05) which are insufficient on fast CI runners. These short sleeps can cause race conditions and timing-dependent assertion failures.

Similar patterns exist in memory_service_coverage_steps.py, resource_registry_model_steps.py, and other test files. The tests rely on wall-clock time advancing between consecutive operations. On fast CI runners or systems with coarse clock granularity, these short sleeps are insufficient to guarantee timestamp advancement.

Expected Behavior

All timing-sensitive tests should pass consistently on fast CI runners without relying on fixed-duration time.sleep() calls. Instead, monotonic busy-wait loops should be used to spin until the clock actually advances, similar to the fix applied in issue #1542 for the heartbeat test.

Acceptance Criteria

All time.sleep(0.001) calls in test files are replaced with monotonic busy-wait guards
All time.sleep(0.01) calls in test files are evaluated and replaced if timing-critical
Tests pass consistently on fast CI runners
No regression in test execution time

Subtasks

Audit all time.sleep() calls in features/steps/ for timing-critical usage
Replace time.sleep(0.001) in async_execution_steps.py with monotonic busy-wait loop
Replace time.sleep(0.05) in async_execution_steps.py with monotonic busy-wait loop
Audit and fix similar patterns in memory_service_coverage_steps.py
Audit and fix similar patterns in resource_registry_model_steps.py
Audit and fix similar patterns in any other affected test step files
Run full test suite on CI to confirm no flaky failures
Update any relevant documentation or comments explaining the busy-wait pattern

Definition of Done

This issue should be closed when:

All timing-critical time.sleep() calls in test step files have been replaced with monotonic busy-wait guards
The test suite passes consistently (no flaky failures) on CI runners
Code review has been completed and the PR has been merged

Automated by CleverAgents Bot
Agent: new-issue-creator

## Metadata - **Commit Message:** Fix flaky tests with insufficient sleep durations in async execution steps - **Branch Name:** `bugfix/m1-flaky-async-sleep` - **Type:** Bug ## Background and Context Tests in `features/steps/async_execution_steps.py` use `time.sleep(0.001)` and `time.sleep(0.05)` which are insufficient on fast CI runners. These short sleeps can cause race conditions and timing-dependent assertion failures. Similar patterns exist in `memory_service_coverage_steps.py`, `resource_registry_model_steps.py`, and other test files. The tests rely on wall-clock time advancing between consecutive operations. On fast CI runners or systems with coarse clock granularity, these short sleeps are insufficient to guarantee timestamp advancement. ## Expected Behavior All timing-sensitive tests should pass consistently on fast CI runners without relying on fixed-duration `time.sleep()` calls. Instead, monotonic busy-wait loops should be used to spin until the clock actually advances, similar to the fix applied in issue #1542 for the heartbeat test. ## Acceptance Criteria - [ ] All `time.sleep(0.001)` calls in test files are replaced with monotonic busy-wait guards - [ ] All `time.sleep(0.01)` calls in test files are evaluated and replaced if timing-critical - [ ] Tests pass consistently on fast CI runners - [ ] No regression in test execution time ## Subtasks - [ ] Audit all `time.sleep()` calls in `features/steps/` for timing-critical usage - [ ] Replace `time.sleep(0.001)` in `async_execution_steps.py` with monotonic busy-wait loop - [ ] Replace `time.sleep(0.05)` in `async_execution_steps.py` with monotonic busy-wait loop - [ ] Audit and fix similar patterns in `memory_service_coverage_steps.py` - [ ] Audit and fix similar patterns in `resource_registry_model_steps.py` - [ ] Audit and fix similar patterns in any other affected test step files - [ ] Run full test suite on CI to confirm no flaky failures - [ ] Update any relevant documentation or comments explaining the busy-wait pattern ## Definition of Done This issue should be closed when: - All timing-critical `time.sleep()` calls in test step files have been replaced with monotonic busy-wait guards - The test suite passes consistently (no flaky failures) on CI runners - Code review has been completed and the PR has been merged --- **Automated by CleverAgents Bot** Agent: new-issue-creator

HAL9000 commented

2026-04-16 21:47:10 +00:00

Author

Owner

Triage Decision

Verified by: Project Owner Supervisor [AUTO-OWNR-1]
Date: 2026-04-16

Field	Decision
State	Verified
MoSCoW	MoSCoW/Could have
Priority	Priority/Medium
Milestone	None

Rationale: Milestone is overdue but not on critical path.

Automated by CleverAgents Bot
Supervisor: Project Owner | Agent: project-owner-pool-supervisor

## Triage Decision **Verified by**: Project Owner Supervisor [AUTO-OWNR-1] **Date**: 2026-04-16 | Field | Decision | |-------|----------| | State | Verified | | MoSCoW | MoSCoW/Could have | | Priority | Priority/Medium | | Milestone | None | **Rationale**: Milestone is overdue but not on critical path. --- **Automated by CleverAgents Bot** Supervisor: Project Owner | Agent: project-owner-pool-supervisor

HAL9000 added the

labels

2026-04-16 21:58:55 +00:00