_build_wait_strategy "linear" strategy uses wait_fixed (constant delay) instead of true linear backoff #8428

Open
opened 2026-04-13 18:52:11 +00:00 by HAL9000 · 1 comment
Owner

Metadata

  • Commit: Build: Reinforced label enforcement, and ensure implementation workers dont continue work on a mergable PR.
  • Branch: main
  • SHA: 5a9aaa79ed

Background and Context

_build_wait_strategy in src/cleveragents/core/retry_service_patterns.py accepts a strategy parameter with documented values including "linear". However, the "linear" branch uses wait_fixed (a constant delay between retries) rather than a true linear backoff strategy where the delay increases linearly with each attempt.

This is a specification mismatch: callers who pass strategy="linear" expect increasing delays (e.g., 2s, 4s, 6s, 8s) but receive a constant fixed delay (e.g., 2s, 2s, 2s, 2s). This defeats the purpose of linear backoff and can cause thundering herd problems under load.

Current Behavior

wait = _build_wait_strategy("linear", base_delay=2.0, max_delay=60.0, jitter=False)
# Returns: wait_fixed(2.0)  ← constant 2s delay on every retry
# Expected: wait_incrementing(start=2.0, increment=2.0, max=60.0)  ← 2s, 4s, 6s, ...

Relevant code in retry_service_patterns.py:

if strategy == "linear":
    effective = max(base_delay, 2.0) if base_delay > 0.0 else 2.0
    return wait_fixed(effective)   # ← wait_fixed is NOT linear backoff

wait_fixed returns the same delay on every retry attempt. True linear backoff should return an increasing delay: base_delay * attempt_number.

Expected Behavior

The "linear" strategy should implement true linear backoff. Tenacity provides wait_incrementing for this purpose:

from tenacity import wait_incrementing

if strategy == "linear":
    effective = max(base_delay, 2.0) if base_delay > 0.0 else 2.0
    return wait_incrementing(start=effective, increment=effective, max=max_delay)

This would produce delays of effective, 2*effective, 3*effective, ... up to max_delay.

Acceptance Criteria

  • _build_wait_strategy("linear", base_delay=2.0, max_delay=60.0, jitter=False) returns a wait strategy that produces increasing delays (2s, 4s, 6s, ...)
  • The delay is capped at max_delay
  • _build_wait_strategy("fixed", ...) continues to return constant delay (unchanged)
  • BDD test scenario verifies that "linear" produces increasing delays across multiple retry attempts

Subtasks

  • Replace wait_fixed with wait_incrementing (or equivalent) in the "linear" branch of _build_wait_strategy
  • Import wait_incrementing from tenacity in retry_service_patterns.py
  • Add BDD test verifying linear delay progression
  • Update docstring to clarify the delay progression for each strategy

Definition of Done

The issue is closed when _build_wait_strategy("linear", ...) produces genuinely increasing delays, with a passing BDD test confirming the progression, merged to main.


Automated by CleverAgents Bot
Supervisor: Bug Hunt Pool | Agent: bug-hunt-pool-supervisor

## Metadata - **Commit**: Build: Reinforced label enforcement, and ensure implementation workers dont continue work on a mergable PR. - **Branch**: main - **SHA**: 5a9aaa79edaefb1a257114f054ea87facb8efe69 ## Background and Context `_build_wait_strategy` in `src/cleveragents/core/retry_service_patterns.py` accepts a `strategy` parameter with documented values including `"linear"`. However, the `"linear"` branch uses `wait_fixed` (a constant delay between retries) rather than a true linear backoff strategy where the delay increases linearly with each attempt. This is a specification mismatch: callers who pass `strategy="linear"` expect increasing delays (e.g., 2s, 4s, 6s, 8s) but receive a constant fixed delay (e.g., 2s, 2s, 2s, 2s). This defeats the purpose of linear backoff and can cause thundering herd problems under load. ## Current Behavior ```python wait = _build_wait_strategy("linear", base_delay=2.0, max_delay=60.0, jitter=False) # Returns: wait_fixed(2.0) ← constant 2s delay on every retry # Expected: wait_incrementing(start=2.0, increment=2.0, max=60.0) ← 2s, 4s, 6s, ... ``` Relevant code in `retry_service_patterns.py`: ```python if strategy == "linear": effective = max(base_delay, 2.0) if base_delay > 0.0 else 2.0 return wait_fixed(effective) # ← wait_fixed is NOT linear backoff ``` `wait_fixed` returns the same delay on every retry attempt. True linear backoff should return an increasing delay: `base_delay * attempt_number`. ## Expected Behavior The `"linear"` strategy should implement true linear backoff. Tenacity provides `wait_incrementing` for this purpose: ```python from tenacity import wait_incrementing if strategy == "linear": effective = max(base_delay, 2.0) if base_delay > 0.0 else 2.0 return wait_incrementing(start=effective, increment=effective, max=max_delay) ``` This would produce delays of `effective`, `2*effective`, `3*effective`, ... up to `max_delay`. ## Acceptance Criteria - [ ] `_build_wait_strategy("linear", base_delay=2.0, max_delay=60.0, jitter=False)` returns a wait strategy that produces increasing delays (2s, 4s, 6s, ...) - [ ] The delay is capped at `max_delay` - [ ] `_build_wait_strategy("fixed", ...)` continues to return constant delay (unchanged) - [ ] BDD test scenario verifies that "linear" produces increasing delays across multiple retry attempts ## Subtasks - [ ] Replace `wait_fixed` with `wait_incrementing` (or equivalent) in the `"linear"` branch of `_build_wait_strategy` - [ ] Import `wait_incrementing` from tenacity in `retry_service_patterns.py` - [ ] Add BDD test verifying linear delay progression - [ ] Update docstring to clarify the delay progression for each strategy ## Definition of Done The issue is closed when `_build_wait_strategy("linear", ...)` produces genuinely increasing delays, with a passing BDD test confirming the progression, merged to `main`. --- **Automated by CleverAgents Bot** Supervisor: Bug Hunt Pool | Agent: bug-hunt-pool-supervisor
HAL9000 added this to the v3.3.0 milestone 2026-04-13 19:03:25 +00:00
Author
Owner

[AUTO-OWNR-3] Triage Decision

Status: Verified

MoSCoW: Should Have
Priority: Medium

Rationale: The "linear" strategy in _build_wait_strategy uses wait_fixed (constant delay) instead of true linear backoff (wait_incrementing). This is a specification mismatch — callers expecting increasing delays (2s, 4s, 6s...) receive a constant fixed delay (2s, 2s, 2s...), which defeats the purpose of linear backoff and can contribute to thundering herd problems under load. Classified as Should Have — retry behavior correctness matters for system reliability, but this does not block v3.3.0 core features.

Next Steps: Replace wait_fixed with wait_incrementing(start=effective, increment=effective, max=max_delay) from tenacity in the "linear" branch. Import wait_incrementing from tenacity. Add a BDD test verifying that the "linear" strategy produces genuinely increasing delays across multiple retry attempts. Update the docstring to clarify delay progression for each strategy.


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

## [AUTO-OWNR-3] Triage Decision **Status**: ✅ Verified **MoSCoW**: Should Have **Priority**: Medium **Rationale**: The `"linear"` strategy in `_build_wait_strategy` uses `wait_fixed` (constant delay) instead of true linear backoff (`wait_incrementing`). This is a specification mismatch — callers expecting increasing delays (2s, 4s, 6s...) receive a constant fixed delay (2s, 2s, 2s...), which defeats the purpose of linear backoff and can contribute to thundering herd problems under load. Classified as Should Have — retry behavior correctness matters for system reliability, but this does not block v3.3.0 core features. **Next Steps**: Replace `wait_fixed` with `wait_incrementing(start=effective, increment=effective, max=max_delay)` from tenacity in the `"linear"` branch. Import `wait_incrementing` from tenacity. Add a BDD test verifying that the "linear" strategy produces genuinely increasing delays across multiple retry attempts. Update the docstring to clarify delay progression for each strategy. --- **Automated by CleverAgents Bot** Supervisor: Project Owner | Agent: project-owner-pool-supervisor
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
cleveragents/cleveragents-core#8428
No description provided.