🔴 CI Failure: Flaky timing test in fetch retry suite

[claude]

🔴 CI Failure Analysis

Workflow: CI (Test Suite)
Run: https://github.com/logosdx/monorepo/actions/runs/19789443650
Branch: master
Commit: 582644e

Failure Summary

Test failed: src/fetch/retry.ts > @logosdx/fetch: retry > can configure a retry per request

Error:

AssertionError: expected 40 to be below 40
 ❯ src/fetch/retry.ts:254:35

Root Cause

This is a flaky timing test with insufficient tolerance for CI environment variability. The test verifies that a retry operation with specific configuration completes within a calculated time boundary:

const calc = (10 * 2) + 20; // Give some buffer (40ms)
expect(end - start).to.be.lessThan(calc); // Expected < 40ms, got exactly 40ms

The test configuration:

• maxAttempts: 2
• baseDelay: 10ms
• useExponentialBackoff: false

Expected duration: ~20ms (10ms × 2 attempts)
Allowed buffer: +20ms (total 40ms)
Actual execution: exactly 40ms (boundary condition failure)

Issue

The 20ms buffer is insufficient for CI environments where timing can be unpredictable due to:

• CPU contention from parallel test execution
• Variable system load
• Timer precision limitations

This is a legitimate test failure caused by timing assumptions, not a code regression. All other tests (1362) passed successfully.

Suggested Fix

Increase the timing tolerance in /home/runner/work/monorepo/monorepo/tests/src/fetch/retry.ts:252:

// Before:
const calc = (10 * 2) + 20; // Give some buffer

// After:
const calc = (10 * 2) + 50; // More generous buffer for CI environments

Or better yet, restructure the test to verify retry behavior without relying on precise timing assertions, such as:

• Verify number of retry attempts via event callbacks
• Check that retries occurred without strict time boundaries
• Use mock timers to control time progression

Priority

Low - This is a test infrastructure issue, not a functional regression. The retry logic works correctly; only the timing assertion is too strict.

Analysis generated by Claude Code