Retry transient provider 500 errors on session start instead of permanently failing #SUPERLOG

[superlog-app]

Summary

When Anthropic's managed sessions API returns a transient 500 api_error during session creation, the worker permanently marks the investigation as start_failed with no retry. This means the affected incident gets no automatic re-investigation — the user's incident remains unresolved unless they manually trigger a new run.

Root Cause

The catch block at the end of startQueuedAgentRunWorkflow in start.ts unconditionally called deps.fail(ctx, "start_failed", ...) for every error thrown from startRunnerSession(). This included transient provider-side errors such as Anthropic's api_error with HTTP 500, which indicate a temporary internal server error — not a permanent configuration or logic failure. The Anthropic SDK already exhausted its internal retries (3 POST attempts visible in the triggering trace) before the error reached application code.

The same workflow already handles transient GitHub failures correctly: isRetryableRepositoryError errors cause the function to log a warning and return without calling fail(), leaving the run in repo_discovery state for the sweep to pick up. Session-start errors had no equivalent path.

Remediation

Adds isRetryableStartError(error: unknown): boolean to StartQueuedAgentRunDeps following the existing retry dep pattern. When the error is retryable, startQueuedAgentRunWorkflow logs a warning and returns — the run stays in repo_discovery and the next sweep retries the start. Non-retryable errors still call deps.fail() as before.

The concrete implementation in start-run.ts checks error.status === 500 && error.error?.type === "api_error" (plain object-property read, no provider-specific import). Permanent failures (400, auth errors, invalid configuration) still hard-fail immediately.

Two new tests cover the retry path and the permanent-failure path.

---

Incident: feisty-yak — 6f311883-f5f1-4a01-be4e-59ee0bcf237c

---

Was this PR helpful? Leave feedback — goes straight to the Superlog team.

---

Summary by cubic

Retries transient provider 500 “api_error” responses on session start instead of permanently failing the run, so incidents auto-retry on the next sweep. This prevents unresolved incidents caused by temporary provider outages.

• Bug Fixes
  • Added isRetryableStartError to deps and updated startQueuedAgentRunWorkflow to skip fail() on retryable errors.
  • Classifies status === 500 && error.type === "api_error" as retryable; non-retryable errors still hard-fail.
  • Leaves runs in repo_discovery for auto retry; added tests for both retry and permanent-failure paths.

^{Written for commit 6ec847f. Summary will update on new commits.}

[superlog-app]

Observability review

All clear — no observability concerns found.

All your logs are super.