Re-triage update: Incorporating the implementation guidance from the reporter's comment — urllib3.Retry is the preferred approach to avoid adding tenacity as a new dependency.

Related issues (unchanged):

Implement a retry mechanism for when a network error occurs #3114 — General retry mechanism for network errors (different call sites, complementary scope)
Failed to cancel TF request (500 from TF) #2829 — TF cancel-request 500 (labeled blocked pending TF-side fix; a retry mechanism here would also mitigate that scenario)

Implementation notes:

Use urllib3.Retry configured on the HTTP session/adapter level so all TF API calls are covered uniformly — avoid sprinkling retry logic at individual call sites
Ensure idempotency: re-submitting a TF request must not create duplicate test runs
If urllib3.Retry proves insufficient for certain call patterns (e.g., non-idempotent POST requests that need application-level deduplication), tenacity remains a viable fallback per the reporter's guidance

Proposed test case:

def test_testing_farm_api_retries_on_500():
    """
    Mock the TF API client to return HTTP 500 on the first two calls
    and succeed on the third. Verify:
    1. The API call eventually succeeds after retries
    2. The call was attempted exactly 3 times
    3. Exponential backoff delays were applied
    4. No duplicate test requests were submitted
    """

def test_testing_farm_api_fails_after_max_retries():
    """
    Mock the TF API client to always return HTTP 500. Verify:
    1. The call fails after the max retry count
    2. An appropriate error is logged/reported
    3. The CI status is updated to reflect the failure
    """

Next steps:

/fs-code — agent creates a PR to implement this issue
/fs-code <your instruction> — agent implements with your specific guidance

Previous run

Related issues:

Implement a retry mechanism for when a network error occurs #3114 — Similar retry mechanism request, but scoped to network errors (e.g., HTTP 502 from Pagure during git clone). That issue covers a different set of call sites; this issue is specifically about Testing Farm API calls.
Failed to cancel TF request (500 from TF) #2829 — Tracks a specific TF cancel-request 500 error, currently labeled blocked pending a fix on TF's side. A retry mechanism here would also help mitigate that scenario.

Proposed test case:

def test_testing_farm_api_retries_on_500():
    """
    Mock the TF API client to return HTTP 500 on the first two calls
    and succeed on the third. Verify:
    1. The API call eventually succeeds after retries
    2. The call was attempted exactly 3 times
    3. Exponential backoff delays were applied
    4. No duplicate test requests were submitted
    """

def test_testing_farm_api_fails_after_max_retries():
    """
    Mock the TF API client to always return HTTP 500. Verify:
    1. The call fails after the max retry count
    2. An appropriate error is logged/reported
    3. The CI status is updated to reflect the failure
    """

Implementation note: Ensure the retry approach is idempotent — re-submitting a TF request should not create duplicate test runs. Consider wrapping TF API calls at the client/session level (e.g., using urllib3.Retry or a custom decorator) rather than adding retry logic at each call site individually.

Labels: This is a feature request to add retry logic to Testing Farm API calls. Labeled as kind/feature for the feature request nature, area/testing-farm for the affected component, gain/high because it would prevent unnecessary CI failures for many users, and complexity/single-task as it is a bounded implementation task.

Next steps:

/fs-code — agent creates a PR to implement this issue
/fs-code <your instruction> — agent implements with your specific guidance

Uh oh!

Implement a retry mechanism for Testing Farm API calls #3164

Description

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions