Skip to content

RAG 5xx/408 indexing failures not paced by StartableToolSet backoff gate (#4060 follow-up) #4097

Description

@aheritier

Context

PR #4062 added a bounded, jittered backoff gate to StartableToolSet, armed by *modelerrors.StatusError (429, 408, 5xx). The gate only arms when a *StatusError survives to startBackoffRetryable — and for RAG indexing, that only reliably happens for 429.

Problem

classifyModelCallError (pkg/rag/strategy/indexing_errors.go) treats 5xx and 408 as transient and swallows them per-file ("continue indexing other files") rather than propagating them out of Manager.Initialize. So a knowledge base whose embedding/chat-model backend is returning sustained 503s or 408s never arms the backoff gate — the indexing burst repeats every loop iteration/turn, exactly the #4060 pattern, just for a different HTTP status family than 429.

This is explicitly documented as a known gap in docs/tools/rag/index.md's retry-policy table (429-only) as of PR #4062.

Acceptance criteria

  • Decide and implement one of: (a) propagate 5xx/408 out of classifyModelCallError/vector_store.go so they reach startLocked and arm the gate, or (b) if intentionally kept per-file-transient, document why sustained-failure amplification cannot occur, with a test pinning that reasoning
  • If (a): add tests mirroring the existing 429 gate tests — a sustained-5xx/408 RAG indexing run arms the backoff gate on the next turn
  • Update docs/tools/rag/index.md's retry-policy table accordingly

Metadata

Metadata

Assignees

Labels

area/ragFor work/issues that have to do with the RAG featuresarea/toolsFor features/issues/fixes related to the usage of built-in and MCP tools

Type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions