Skip to content

fix(executor): preserve non-retryable tool failures - #7621

Open
BillLeoutsakosvl346 wants to merge 1 commit into
stagingfrom
fix/platform-non-retryable-errors
Open

fix(executor): preserve non-retryable tool failures#7621
BillLeoutsakosvl346 wants to merge 1 commit into
stagingfrom
fix/platform-non-retryable-errors

Conversation

@BillLeoutsakosvl346

Copy link
Copy Markdown
Contributor

Summary

  • Preserve an explicit retryable: false from failed generic tool results using the existing NonRetryableExecutionError mechanism.
  • Retain the existing failure message, status, output, and block/tool metadata. Ordinary failures keep their existing retry behavior.
  • Extend existing handler and executor tests, including a real generic handler running through configured block retries.

Validation

  • 44 tests pass across the generic handler, block executor retry, and retry-policy suites (maxWorkers=2).
  • The two new false-classification regression cases fail against the old implementation; executor reproduction makes three attempts instead of one.
  • App type-check, changed-file Biome, API validation, and git diff --check pass.
  • No retry-policy redesign, integration-specific behavior, or generated changes.

@vercel

vercel Bot commented Sep 8, 2026

Copy link
Copy Markdown

The latest updates on your projects. Learn more about Vercel for GitHub.

1 Skipped Deployment
Project Deployment Actions Updated
docs Skipped Skipped Sep 8, 2026 11:20pm UTC

Request Review

@greptile-apps

greptile-apps Bot commented Sep 8, 2026

Copy link
Copy Markdown
Contributor

RetriggerView in GreptileConfidence Score: 5/5

The PR appears safe to merge; the intended non-retryable path is recognized by the existing executor policy without disrupting ordinary retries or failure handling.

Summary

  • Generic tool failures marked non-retryable now stop after the first attempt.
  • Failures marked retryable or without an explicit classification continue using the configured block retry policy.
  • Existing failure messages, status codes, outputs, and block/tool metadata remain attached.
  • Handler-level and executor-level regression coverage verifies the classification and retry behavior.

Diagram

%%{init: {'theme': 'neutral'}}%%
flowchart TD
  A[Generic tool returns failure] --> B{retryable equals false?}
  B -- Yes --> C[Throw NonRetryableExecutionError]
  B -- No or absent --> D[Throw ordinary Error]
  C --> E[Block executor stops retrying]
  D --> F{Retry attempts remain?}
  F -- Yes --> G[Retry tool execution]
  G --> A
  F -- No --> H[Record final block failure]
  E --> H
Loading

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant