fix(failover): recognize 'abort' stop reason as timeout for model fallback by sauerdaniel · Pull Request #18618 · openclaw/openclaw

sauerdaniel · 2026-02-16T22:34:16Z

Problem

When streaming providers (GLM, OpenRouter, NVIDIA NIM, etc.) return stop reason: abort due to stream interruption, OpenClaw's failover mechanism did not recognize this as a timeout condition. This prevented fallback models from being triggered, leaving users with failed requests instead of graceful failover to secondary models.

Root Cause

The timeout error pattern detection in two places did not include abort-related patterns:

ERROR_PATTERNS.timeout in src/agents/pi-embedded-helpers/errors.ts
TIMEOUT_HINT_RE in src/agents/failover-error.ts

Solution

Add abort stop reason patterns to both timeout detection regexes:

/\bstop reason:\s*abort\b/i
/\breason:\s*abort\b/i
/\bunhandled stop reason:\s*abort\b/i

Impact

Affects all users configuring model fallback chains with streaming providers. Before this fix, any abort from the provider would surface as a user-facing error instead of triggering the next model in the fallback chain.

Testing

TypeScript compilation passes
Lint passes
Pattern logic is unit-testable via existing error classification helpers

Fixes #18453

AI-Assisted

This PR was prepared with assistance from Claude Opus 4.5.

Greptile Summary

This PR adds abort stop reason pattern detection to both timeout error classification paths (failover-error.ts and errors.ts), enabling model fallback when streaming providers (GLM, OpenRouter, NVIDIA NIM) return stop reason: abort due to stream interruption.

Adds stop reason:\s*abort and unhandled stop reason:\s*abort patterns to TIMEOUT_HINT_RE in failover-error.ts
Adds three regex patterns (stop reason:\s*abort, reason:\s*abort, unhandled stop reason:\s*abort) to ERROR_PATTERNS.timeout in errors.ts
Inconsistency: The broader reason:\s*abort pattern exists only in errors.ts but not in failover-error.ts, which means the two timeout detection codepaths (isTimeoutError vs isTimeoutErrorMessage) will behave differently for error messages containing "reason: abort" without the "stop" prefix

Confidence Score: 3/5

Low-risk regex additions with a minor pattern inconsistency between the two detection paths that could cause edge-case behavioral differences.
The core change is correct and addresses a real gap in abort detection for streaming providers. However, the reason:\s*abort pattern is present in errors.ts but missing from failover-error.ts, creating an inconsistency between the two timeout classification paths. This means certain error messages may be classified as timeouts in one path but not the other, potentially causing subtle failover behavior differences. The redundant unhandled stop reason pattern is a minor style concern.
src/agents/failover-error.ts — missing reason:\s*abort pattern that exists in errors.ts

_{Last reviewed commit: d77099a}

Local Validation

pnpm build && pnpm check

TypeScript compilation passes. Lint passes. Pattern logic is unit-testable via existing error classification helpers.

…lback When streaming providers (GLM, OpenRouter, etc.) return 'stop reason: abort' due to stream interruption, OpenClaw's failover mechanism did not recognize this as a timeout condition. This prevented fallback models from being triggered, leaving users with failed requests instead of graceful failover. Changes: - Add abort patterns to ERROR_PATTERNS.timeout in pi-embedded-helpers/errors.ts - Extend TIMEOUT_HINT_RE regex to include abort patterns in failover-error.ts Fixes openclaw#18453 Co-authored-by: James <james@openclaw.ai>

greptile-apps

_{2 files reviewed, 2 comments}

_{Edit Code Review Agent Settings | Greptile}

greptile-apps · 2026-02-16T22:37:47Z

+const TIMEOUT_HINT_RE =
+  /timeout|timed out|deadline exceeded|context deadline exceeded|stop reason:\s*abort|unhandled stop reason:\s*abort/i;


Pattern mismatch with errors.ts

ERROR_PATTERNS.timeout in errors.ts includes the broad /\breason:\s*abort\b/i pattern, but TIMEOUT_HINT_RE here does not. This means the two timeout detection paths behave differently: isTimeoutErrorMessage() (errors.ts) will classify a message containing "reason: abort" as a timeout, but hasTimeoutHint() / isTimeoutError() (this file) will not.

This could cause inconsistent behavior — e.g., a provider error surfaced as an error message string would trigger failover via classifyFailoverReason → isTimeoutErrorMessage, but the same text passed through resolveFailoverReasonFromError → isTimeoutError would miss it.

If reason:\s*abort (without "stop" prefix) is a real pattern from providers, consider adding it here too for consistency:

Suggested change

const TIMEOUT_HINT_RE =

/timeout|timed out|deadline exceeded|context deadline exceeded|stop reason:\s*abort|unhandled stop reason:\s*abort/i;

const TIMEOUT_HINT_RE =

/timeout|timed out|deadline exceeded|context deadline exceeded|stop reason:\s*abort|reason:\s*abort|unhandled stop reason:\s*abort/i;

Prompt To Fix With AI

This is a comment left during a code review. Path: src/agents/failover-error.ts Line: 3:4 Comment: **Pattern mismatch with `errors.ts`** `ERROR_PATTERNS.timeout` in `errors.ts` includes the broad `/\breason:\s*abort\b/i` pattern, but `TIMEOUT_HINT_RE` here does not. This means the two timeout detection paths behave differently: `isTimeoutErrorMessage()` (errors.ts) will classify a message containing "reason: abort" as a timeout, but `hasTimeoutHint()` / `isTimeoutError()` (this file) will not. This could cause inconsistent behavior — e.g., a provider error surfaced as an error message string would trigger failover via `classifyFailoverReason` → `isTimeoutErrorMessage`, but the same text passed through `resolveFailoverReasonFromError` → `isTimeoutError` would miss it. If `reason:\s*abort` (without "stop" prefix) is a real pattern from providers, consider adding it here too for consistency: ```suggestion const TIMEOUT_HINT_RE = /timeout|timed out|deadline exceeded|context deadline exceeded|stop reason:\s*abort|reason:\s*abort|unhandled stop reason:\s*abort/i; ``` How can I resolve this? If you propose a fix, please make it concise.

greptile-apps · 2026-02-16T22:37:48Z

+    /\bstop reason:\s*abort\b/i,
+    /\breason:\s*abort\b/i,
+    /\bunhandled stop reason:\s*abort\b/i,


Redundant pattern: unhandled stop reason already matched

/\bstop reason:\s*abort\b/i will already match the substring "stop reason: abort" inside "unhandled stop reason: abort" (since \b fires at the word boundary before "stop"). This makes /\bunhandled stop reason:\s*abort\b/i on line 604 redundant — it can never match something that line 602 wouldn't already catch.

Not a bug, but worth simplifying to reduce maintenance surface:

Suggested change

/\bstop reason:\s*abort\b/i,

/\breason:\s*abort\b/i,

/\bunhandled stop reason:\s*abort\b/i,

/\bstop reason:\s*abort\b/i,

/\breason:\s*abort\b/i,

_{Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!}

Prompt To Fix With AI

This is a comment left during a code review. Path: src/agents/pi-embedded-helpers/errors.ts Line: 602:604 Comment: **Redundant pattern: `unhandled stop reason` already matched** `/\bstop reason:\s*abort\b/i` will already match the substring "stop reason: abort" inside "unhandled stop reason: abort" (since `\b` fires at the word boundary before "stop"). This makes `/\bunhandled stop reason:\s*abort\b/i` on line 604 redundant — it can never match something that line 602 wouldn't already catch. Not a bug, but worth simplifying to reduce maintenance surface: ```suggestion /\bstop reason:\s*abort\b/i, /\breason:\s*abort\b/i, ``` <sub>Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!</sub> How can I resolve this? If you propose a fix, please make it concise.

greptile-apps Bot reviewed Feb 16, 2026

View reviewed changes

openclaw-barnacle Bot added agents Agent runtime and tooling size: XS labels Feb 16, 2026

steipete merged commit 12ce358 into openclaw:main Feb 16, 2026
26 checks passed

monkeygold mentioned this pull request Feb 28, 2026

Failover not triggered for network_error stop reason #29429

Closed

dapingzui mentioned this pull request Mar 12, 2026

[Bug] Unhandled Stop Reason "sensitive" Crashes Agent and Stalls Telegram Polling #43607

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

fix(failover): recognize 'abort' stop reason as timeout for model fallback#18618

fix(failover): recognize 'abort' stop reason as timeout for model fallback#18618
steipete merged 1 commit intoopenclaw:mainfrom
sauerdaniel:fix/failover-abort-pattern

sauerdaniel commented Feb 16, 2026 •

edited

Loading

Uh oh!

greptile-apps Bot left a comment

Uh oh!

greptile-apps Bot Feb 16, 2026

Uh oh!

greptile-apps Bot Feb 16, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

		const TIMEOUT_HINT_RE =
		/timeout\|timed out\|deadline exceeded\|context deadline exceeded\|stop reason:\sabort\|unhandled stop reason:\sabort/i;

Uh oh!

Conversation

sauerdaniel commented Feb 16, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Problem

Root Cause

Solution

Impact

Testing

AI-Assisted

Greptile Summary

Confidence Score: 3/5

Local Validation

Uh oh!

greptile-apps Bot left a comment

Choose a reason for hiding this comment

Uh oh!

greptile-apps Bot Feb 16, 2026

Choose a reason for hiding this comment

Uh oh!

greptile-apps Bot Feb 16, 2026

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

sauerdaniel commented Feb 16, 2026 •

edited

Loading