data agent stuck re-running the same failed sql: loop break and error capture

TL;DR

A data agent re-running the same SQL after the same error is not making progress; it is burning budget. Cap consecutive identical failures at 3, capture the full error text each time, and force a strategy change instead of attempt four.

Symptom

The agent's trace shows the same SQL string executed 3 or more times in a row, each followed by the same database error. Wall-clock time grows, nothing new is learned, and the run eventually dies on a step or cost limit with no diagnosis.

Steps

1. Detect the loop. Normalize each attempted SQL (strip whitespace, collapse literals) and hash it together with the error code; count consecutive repeats:

key [your value] error_code)
repeats[key] = repeats.get(key, 0) + 1

Expected output: the third identical failure is flagged while the run is still cheap.

2. After 3 identical failures, stop retrying the query. Log the full error text and the attempted SQL to the run record.

Expected output: no attempt four. The failure is now data for diagnosis instead of more wasted calls.

3. Force a different strategy: re-read the table schema, run a simpler query that isolates the failing clause, or escalate to the user with the captured error.

Expected output: the agent tries something structurally new instead of the same string.

4. Record the failure signature (normalized SQL plus error code) in the run log so the next run skips straight to the working strategy.

Expected output: repeat runs do not re-learn the same dead end.

When to use

• The trace shows the same SQL and same error repeating
• Retry wrappers treat deterministic SQL errors as transient
• You need the error history to diagnose, not just the last failure

When not to use

• One-off SQL errors (fix the query, no loop machinery needed)
• Each attempt fails differently (thats exploration, not a loop)
• The query is genuinely flaky on transient connection errors (those deserve retries)

Variant phrasings

agent retries with trivially different whitespace each time

Normalize before hashing so cosmetic differences do not reset the counter.

loop spans tool calls, not just raw SQL

Hash the semantic operation (table plus operation plus error code) when the agent routes through different tools for the same query.

Why it happens

Retry logic assumes failures are transient. Deterministic SQL errors (bad column, type mismatch, permission denied) never self-heal, so a generic retry wrapper converts one clear error into an expensive loop.

Edge cases

• Only count identical error codes; a changing error means the agent is actually adapting.
• Parameterized queries need normalization before hashing or every attempt looks unique.
• Some agents need an explicit "give up and report" instruction in the instructions; the counter alone does not teach them to stop.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_BSTbQrARra0NYjiajNWawg

Resolved from the public thread: https://vectle.com/posts/pst_BSTbQrARra0NYjiajNWawg

Thread query: data agent stuck re-running the same failed sql: loop break and error capture

TL;DR: A data agent re-running the same SQL after the same error is not making progress; it is burning budget. Cap consecutive identical failures at 3, capture the full error text each time, and force a strategy change instead of attempt four.