fix(runtime): retry transient mid-stream provider errors instead of crashing the scan

[devin-ai-integration]

Summary

A transient upstream provider error raised mid-stream currently propagates out of _run_cycle and kills the entire scan (in non-interactive mode if not interactive: raise), tearing down every live agent.

The most common shape is a bare openai.APIError with no status code: after the HTTP request has already returned 200 and tokens have started streaming, the server injects an {"error": ...} frame into the SSE stream and the OpenAI SDK raises APIError("An error occurred while processing the request."). The agents SDK's own retry can't replay this — once tokens have streamed it treats the turn as retry-unsafe — so it re-raises and the whole run dies.

This adds a bounded, turn-level retry in _run_cycle for transient model/provider errors, sitting alongside the existing image-strip and context-overflow recovery branches:

if model_retries < _MAX_TRANSIENT_MODEL_RETRIES and _is_transient_model_error(exc):
    model_retries += 1
    await asyncio.sleep(_transient_model_retry_delay(model_retries))  # 2s→4s→8s→16s, capped 30s
    if session is not None:
        input_data = []   # input already persisted to the session before the model call;
                          # replay from session state instead of re-appending it
    continue

Classification (_is_transient_model_error):

error	retried here?
network faults (APIConnectionError, APITimeoutError)	yes
APIStatusError with 408 / 500 / 502 / 503 / 504	yes
bare APIError (no status code) — the mid-stream case	yes
RateLimitError (429)	no — already handled as a graceful, resumable scan stop in runner.run_strix_scan
permanent 4xx client errors (400/401/403/404/422 …)	no
everything non-provider (ValueError, etc.)	no

After _MAX_TRANSIENT_MODEL_RETRIES (4) exhausted attempts the error propagates as before, so a genuine sustained outage still fails the scan rather than looping forever.

Replaying with input_data = [] when a session is present is correct because the turn's input is persisted to the session before the model streams (in the SDK's streamed run loop), so re-running the turn reads it back from session state rather than duplicating it — the same pattern the existing image-strip / compaction recovery already relies on.

Tests

New tests/test_execution_transient_retry.py:

• classifier coverage for each family above (mid-stream APIError, network errors, 5xx, rate limit exclusion, permanent 4xx, non-provider errors);
• _run_cycle replays a mid-stream APIError and succeeds on the next attempt;
• _run_cycle gives up and propagates after the retry bound;
• _run_cycle does not retry a permanent client error.

Link to Devin session: https://app.devin.ai/sessions/dad023e379e942f287bcf6822463b7a4
Requested by: @0xallam

[devin-ai-integration]

🤖 Devin AI Engineer

I'll be helping with this pull request! Here's what you should know:

✅ I will automatically:

• Address comments on this PR. Add '(aside)' to your comment to have me ignore it.
• Look at CI failures and help fix them

Note: I can only respond to comments from users who have write access to this repository.

⚙️ Control Options:

• Disable automatic comment, CI, and merge conflict monitoring

[greptile-apps]

Greptile Summary

Adds bounded turn-level recovery for transient model-provider failures.

• Classifies connection failures, timeouts, selected HTTP status errors, and status-less mid-stream API errors as retryable.
• Retries failed turns with exponential backoff while preserving session replay semantics and existing rate-limit handling.
• Adds classifier and _run_cycle coverage for successful retries, exhausted retries, and permanent errors.

Confidence Score: 5/5

The PR appears safe to merge with no actionable defects identified.

The retry path is bounded, preserves existing handling for rate limits and permanent failures, and propagates sustained transient failures after exhaustion.

Important Files Changed

Filename	Overview
strix/core/execution.py	Adds bounded transient-provider retry classification and replay handling without changing permanent-error or rate-limit behavior.
tests/test_execution_transient_retry.py	Adds focused coverage for error classification, successful replay, retry exhaustion, and non-retryable client failures.

_{Reviews (1): Last reviewed commit: "fix(runtime): retry transient mid-stream..." | Re-trigger Greptile}