agent loop detected: data quality agent retries same great expectations checkpoint after config error

TL;DR

Treat a configuration error as a stop, not a retry: the agent reruns the same Great Expectations checkpoint after a config error, and config errors do not heal, so classify the failure and halt the loop until the configuration changes. Retries are for transient failures. A checkpoint that cannot load its configuration fails before touching data, identically, forever, and each rerun costs a full agent cycle.

agent loop detected: data quality agent retries same great expectations checkpoint after config error

Use this when

• The check or run fails with this symptom: an agent loop retries the same Great Expectations checkpoint after a configuration error.
• You are working on an agent workflow running Great Expectations checkpoints with automatic retries and the failure repeats on the same data or configuration.
• You need the failing rows, rule, or stage isolated before changing thresholds or code.

Not for this skill when

• A checkpoint failing on a transient warehouse connection, where a bounded retry is the right behaviour.
• The error text names a different tool, stage, or root cause. Match the verbatim error first and use that skill.

Steps

1. Read the checkpoint failure and classify it: configuration load, connection, or validation. Verify: the failure is a configuration error raised before validation
2. Fix the configuration fault named in the error, such as a missing store or a bad reference. Verify: the checkpoint loads its configuration in a dry run
3. Set the retry policy to retry only connection and transient classes, with a small cap. Verify: a config error now stops the workflow on first occurrence
4. Key retries on a hash of the configuration so any edit re-enables a run. Verify: an edited config runs without manual reset
5. Report the halted state with the config error attached. Verify: a human sees the blocker immediately

Variant phrasings

agent retries great expectations checkpoint config error loop

The shorter phrasing focused on the named failure.

agent loop same checkpoint configuration error

The symptom phrasing a searcher tries next.

checkpoint retry policy config error fix

The variant naming the failing stage or tool directly.

Compatibility: Great Expectations checkpoint execution, agent retry policies

Why it happens

Retry loops usually key on exit status alone. Configuration errors and validation failures share a non-zero exit with transient faults, so an undiscriminating loop retries permanent failures and never escalates the one thing a human must change.

Edge cases / pitfalls

• Distinguish validation failure from execution failure in the report; a failed expectation is a result, not an error to retry.
• A config hash must include referenced files such as expectation suites, not only the checkpoint file itself.

Provenance

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

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

Thread query: agent loop detected: data quality agent retries same great expectations checkpoint after config error

TL;DR: Treat a configuration error as a stop, not a retry: the agent reruns the same Great Expectations checkpoint after a config error, and config errors do not heal, so classify the failure and halt the loop until the configuration changes. Retries are for transient failures. A checkpoint that cannot load its configuration fails before touching data, identically, forever, and each rerun costs a full agent cycle.