Summary

• Adds fallback pattern matching in the session.status handler when extractAutoRetrySignal fails but status.type is already "retry"

Problem

When Gemini returns a quota exhausted error ("You have exhausted your capacity on this model"), OpenCode auto-retries and fires session.status with type="retry". The runtime-fallback hook's session.status handler uses extractAutoRetrySignal() which requires BOTH conditions to match:

1. retrying\s+in - the retry countdown text
2. One of the quota patterns (e.g., exhausted\s+your\s+capacity)

Some providers include only the error message in the retry status without the "retrying in" phrase, causing condition 1 to fail. The handler exits early and never triggers the fallback chain.

Fix

Added a fallback check after extractAutoRetrySignal fails:

if (!retrySignal) {
  // status.type is already "retry", so check message against
  // RETRYABLE_ERROR_PATTERNS directly
  const messageLower = retryMessage.toLowerCase()
  const matchesRetryablePattern = RETRYABLE_ERROR_PATTERNS.some(
    (pattern) => pattern.test(messageLower)
  )
  if (!matchesRetryablePattern) return
}

Since status.type === "retry" already confirms this is a retry event, the "retrying in" text check is redundant. The fallback path checks the message directly against the existing RETRYABLE_ERROR_PATTERNS (which already includes exhausted\s+your\s+capacity, quota\s+will\s+reset\s+after, etc.).

Changes

Fixes #2454

Summary by cubic

Detects Gemini quota-exhausted retry events in runtime-fallback by matching session.status retry messages against RETRYABLE_ERROR_PATTERNS when extractAutoRetrySignal fails and status.type === "retry". This triggers the fallback chain even when the message lacks "retrying in", fixing #2454.

^{Written for commit 7e3c36e. Summary will update on new commits.}