@@ -129,15 +129,18 @@ validation failures) are treated as failover‑worthy and use the same cooldowns
|
129 | 129 | OpenAI-compatible stop-reason errors such as `Unhandled stop reason: error`, |
130 | 130 | `stop reason: error`, and `reason: error` are classified as timeout/failover |
131 | 131 | signals. |
132 | | -Provider-scoped generic server text can also land in that timeout bucket when |
133 | | -the source matches a known transient pattern. For example, Anthropic bare |
134 | | -`An unknown error occurred` and JSON `api_error` payloads with transient server |
135 | | -text such as `internal server error`, `unknown error, 520`, `upstream error`, |
136 | | -or `backend error` are treated as failover-worthy timeouts. OpenRouter-specific |
137 | | -generic upstream text such as bare `Provider returned error` is also treated as |
138 | | -timeout only when the provider context is actually OpenRouter. Generic internal |
139 | | -fallback text such as `LLM request failed with an unknown error.` stays |
140 | | -conservative and does not trigger failover by itself. |
| 132 | +Generic server text can also land in that timeout bucket when the source matches |
| 133 | +a known transient pattern. For example, the bare pi-ai stream-wrapper message |
| 134 | +`An unknown error occurred` is treated as failover-worthy for every provider |
| 135 | +because pi-ai emits it when provider streams end with `stopReason: "aborted"` or |
| 136 | +`stopReason: "error"` without specific details. JSON `api_error` payloads with |
| 137 | +transient server text such as `internal server error`, `unknown error, 520`, |
| 138 | +`upstream error`, or `backend error` are also treated as failover-worthy |
| 139 | +timeouts. |
| 140 | +OpenRouter-specific generic upstream text such as bare `Provider returned error` |
| 141 | +is treated as timeout only when the provider context is actually OpenRouter. |
| 142 | +Generic internal fallback text such as `LLM request failed with an unknown |
| 143 | +error.` stays conservative and does not trigger failover by itself. |
141 | 144 | |
142 | 145 | Some provider SDKs may otherwise sleep for a long `Retry-After` window before |
143 | 146 | returning control to OpenClaw. For Stainless-based SDKs such as Anthropic and |
|