## TL;DR
Stop scanning the full warehouse in one checkpoint run: give the agent a bounded batch, such as the latest partition or a sampled batch with explicit sampling parameters, checkpoint progress per expectation, and raise the run timeout only after the batch is bounded. A checkpoint that must finish inside an agent timeout has to be sized to the timeout, not the other way round.

```text
agent timed out when agent tried to run great expectations checkpoint on full warehouse scan
```

## Use this when
- The check or run fails with this symptom: the agent's checkpoint run times out before validation completes.
- You are working on an agent running a Great Expectations checkpoint that times out on a full scan 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 human-run checkpoint with no agent timeout, where batch sizing is a performance concern rather than a failure instead.
- The error text names a different tool, stage, or root cause. Match the verbatim error first and use that skill.

## Steps
1. Record the batch the checkpoint tried to load: table size, partition range, and whether a filter or sampler was applied. Verify: the attempted batch scope is documented
2. Change the agent's run plan to validate the latest partition or a defined sample, passing batch parameters explicitly instead of the whole table. Verify: the agent's next run uses a bounded batch
3. Add per-expectation progress logging so a timeout leaves a record of what completed and what did not. Verify: progress is recorded per expectation during the run
4. Set the agent timeout from a measured run on the bounded batch, with headroom, rather than a global default. Verify: the timeout is derived from a measured bounded run
5. Run the bounded checkpoint end to end inside the timeout and confirm results are stored for every expectation. Verify: the checkpoint completes and all results are stored

## Variant phrasings
### agent timed out great expectations checkpoint full scan
The verbatim agent-checkpoint phrasing.
### great expectations checkpoint too slow partition batch
The partitioning phrasing for bounded batches.
### agent checkpoint timeout sampled validation run
The sampling phrasing for representative batches.

Compatibility: Great Expectations checkpoints run by an agent on warehouse-scale tables

## Why it happens
Checkpoints validate whatever batch they are handed, and an agent that hands over an entire warehouse table turns a validation job into a full scan. Agent runtimes enforce wall-clock limits that batch warehouse jobs do not, so the unbounded batch and the fixed timeout collide predictably.

## Edge cases / pitfalls
- Sampling must be deterministic for a given batch so reruns compare like with like.
- Keep one periodic full-table validation outside the agent loop so sampling never becomes the only coverage.

## Provenance

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