What happened
The review agent for PR #13 failed in workflow run 33521688590 because the pre-flight connectivity check received HTTP 403 from the sandbox proxy when testing GET https://api.github.com/rate_limit. The sandbox had been created successfully, skills uploaded, and project code copied — but the single-attempt connectivity check failed and the entire run was aborted. The agent never executed. No other runs in the last 30 on this repo had the same failure, indicating a transient proxy issue.
What could go better
The pre-flight connectivity check currently makes a single request and fails immediately on any non-success response. Transient proxy issues (slow allowlist propagation, ephemeral gateway errors) should not permanently fail a run that has already spent ~60 seconds on sandbox setup. Issue #6828 tracks a similar retry gap for the openshell binary download, but the connectivity check is a distinct code path. Issue #4016 proposes bypassing the check for retro agents specifically, which is a different approach. Neither covers retry-with-backoff for the general pre-flight check. Confidence: high that retry would have resolved this specific failure (the proxy worked for all other runs that day). Moderate confidence that this pattern recurs often enough to warrant the fix — only 1 occurrence in the last 30 runs, but the cost of a failed run (wasted sandbox setup time, missed review) is high relative to the cost of a few retries.
Proposed change
In the harness pre-flight connectivity check (the code that runs GET https://api.github.com/rate_limit from inside the sandbox), add retry with exponential backoff: 3 attempts with delays of 2s, 5s, and 10s. Only retry on HTTP 403 and network-level errors (connection refused, timeout), not on 401/404 which indicate real auth or config problems. Log each retry attempt so transient failures are visible in the run log even when they self-resolve.
Validation criteria
The next transient sandbox proxy 403 during a pre-flight check should be retried and succeed without failing the run. Verify by checking that: (1) the retry logic appears in the harness source, (2) a synthetic test or integration test simulates a transient 403 followed by success, and (3) the run log shows retry attempts when they occur. Non-transient failures (persistent 403, 401) should still fail after exhausting retries.
Generated by retro agent from rhdh-parasol/node-api#13
What happened
The review agent for PR #13 failed in workflow run 33521688590 because the pre-flight connectivity check received HTTP 403 from the sandbox proxy when testing
GET https://api.github.com/rate_limit. The sandbox had been created successfully, skills uploaded, and project code copied — but the single-attempt connectivity check failed and the entire run was aborted. The agent never executed. No other runs in the last 30 on this repo had the same failure, indicating a transient proxy issue.What could go better
The pre-flight connectivity check currently makes a single request and fails immediately on any non-success response. Transient proxy issues (slow allowlist propagation, ephemeral gateway errors) should not permanently fail a run that has already spent ~60 seconds on sandbox setup. Issue #6828 tracks a similar retry gap for the openshell binary download, but the connectivity check is a distinct code path. Issue #4016 proposes bypassing the check for retro agents specifically, which is a different approach. Neither covers retry-with-backoff for the general pre-flight check. Confidence: high that retry would have resolved this specific failure (the proxy worked for all other runs that day). Moderate confidence that this pattern recurs often enough to warrant the fix — only 1 occurrence in the last 30 runs, but the cost of a failed run (wasted sandbox setup time, missed review) is high relative to the cost of a few retries.
Proposed change
In the harness pre-flight connectivity check (the code that runs
GET https://api.github.com/rate_limitfrom inside the sandbox), add retry with exponential backoff: 3 attempts with delays of 2s, 5s, and 10s. Only retry on HTTP 403 and network-level errors (connection refused, timeout), not on 401/404 which indicate real auth or config problems. Log each retry attempt so transient failures are visible in the run log even when they self-resolve.Validation criteria
The next transient sandbox proxy 403 during a pre-flight check should be retried and succeed without failing the run. Verify by checking that: (1) the retry logic appears in the harness source, (2) a synthetic test or integration test simulates a transient 403 followed by success, and (3) the run log shows retry attempts when they occur. Non-transient failures (persistent 403, 401) should still fail after exhausting retries.
Generated by retro agent from rhdh-parasol/node-api#13