Retry applied to all block types, not just LLM blocks

The withRetry wrapper is placed around every block's handler execution — not just AI/LLM blocks. This means any block that calls an external service (HTTP request blocks, webhook blocks, database blocks, email blocks, etc.) will also be retried up to 3 times on a 429 or 503 response.

For non-idempotent operations — e.g. sending an email, creating a database row, triggering a webhook — this can silently create 2–4 duplicate operations per execution. The PR description says "all agent blocks automatically retry," but the implementation actually retries all block types.

Consider either:

1. Only retrying within the LLM/AI provider layer (not at the block executor level), or
2. Checking the block type before applying retry logic:

const isLLMBlock = /* check block.metadata?.id against known LLM block types */
const output = isLLMBlock
  ? await withRetry(() => handler.executeWithNode ? ... : ...)
  : await (handler.executeWithNode ? ... : ...)

Fixed in 70ce97f — addressed all review feedback: scoped retries to LLM blocks only, added isNetworkError() for statusless errors, added Retry-After support for 503, and added afterEach vi.useRealTimers() to tests.

All statusless errors trigger retries, including non-transient JS errors

When status === null (no .status or .statusCode on the thrown error), isRetryable is true. This catches genuine network errors — but it also retries any JavaScript runtime error, validation error, or unexpected exception that doesn't carry a status code.

For example, a TypeError, RangeError, or any internal error thrown by a block handler will be silently retried 3 times with up to 30 seconds of total delay before finally failing. This masks bugs and significantly degrades the user-facing error latency for logic errors.

Consider reversing the default: treat unknown errors as non-retryable unless the error is explicitly recognized as transient (e.g., it is a known network error type, or it matches a recognizable pattern):

const isRetryable =
  status !== null
    ? retryableStatusCodes.includes(status)
    : isNetworkError(error) // helper that checks error.code, error.name, etc.

Fixed in 70ce97f — addressed all review feedback: scoped retries to LLM blocks only, added isNetworkError() for statusless errors, added Retry-After support for 503, and added afterEach vi.useRealTimers() to tests.

Retry-After header not respected for 503 responses

The Retry-After header is parsed and used only when status === 429. However, RFC 7231 §7.1.3 specifies that servers sending 503 Service Unavailable may also include a Retry-After header to signal when the service will recover. Both OpenAI and Anthropic can send 503s with Retry-After.

// suggestion
      if (responseHeaders && (status === 429 || status === 503)) {
        const retryAfterMs = parseRetryAfterHeader(responseHeaders)
        delayMs = retryAfterMs ?? calculateBackoffDelay(attempt, initialDelayMs, maxDelayMs)
      } else {
        delayMs = calculateBackoffDelay(attempt, initialDelayMs, maxDelayMs)
      }

Fixed in 70ce97f — addressed all review feedback: scoped retries to LLM blocks only, added isNetworkError() for statusless errors, added Retry-After support for 503, and added afterEach vi.useRealTimers() to tests.

Missing afterEach to restore real timers

vi.useFakeTimers() is called in beforeEach but there is no corresponding vi.useRealTimers() in an afterEach. If Vitest runs these tests in the same worker as other test files that depend on real timers (e.g. setTimeout, Date.now()), the leaked fake timer state can cause subtle test failures elsewhere.

afterEach(() => {
  vi.useRealTimers()
})

Fixed in 70ce97f — addressed all review feedback: scoped retries to LLM blocks only, added isNetworkError() for statusless errors, added Retry-After support for 503, and added afterEach vi.useRealTimers() to tests.

Jitter eliminated when backoff delay reaches max cap

Low Severity

In calculateBackoffDelay, capped is already clamped to maxDelayMs, but then jitter is added to capped and the result is clamped again by Math.min(..., maxDelayMs). When exponential >= maxDelayMs, the jitter is always clamped back to zero, producing a deterministic maxDelayMs with no randomization. This defeats the purpose of jitter (preventing thundering herd) once the exponential component reaches the cap. The jitter needs to be subtracted from (or applied within) capped rather than added on top of it.