## TL;DR
The agent retries the full dump because it never checkpoints, so every attempt starts from zero and times out the same way. Dump one table at a time, lean on sqlmap's own session resume, and cap dump attempts at two before reporting partial data honestly.

```text
(agent re-runs: sqlmap -u URL --dump after each timeout; no rows saved)
```

## Use this when
- The agent log shows repeated identical sqlmap dump commands against the same authorized app, each timing out.
- No dumped rows are ever saved between attempts.

## Not for this skill when
- Sqlmap cannot connect or detect the injection. Those are earlier-stage failures with their own fixes.
- The dump succeeds slowly. Slow success is a pacing problem, not a loop.

## Steps
1. Confirm no progress is being saved: check the sqlmap output directory for partial CSV files. Verify: attempts leave nothing behind, proving the retry is truly from zero.
2. Break the dump into per-table runs: enumerate tables first, then dump the priority tables one by one. Verify: each table dump is its own keyed attempt with its own output file.
3. Let sqlmap resume itself: keep the session files and answer yes to resume on the next run instead of starting over. Verify: the retry continues from the saved session rather than re-testing the injection.
4. Cap dump attempts at two per table; after that, report what was recovered and mark the rest as unrecoverable in this run. Verify: the third identical dump never launches.
5. If the engagement needs the full data, escalate to the tester with the timeout evidence: the fix may be a longer window or a different technique, not more retries. Verify: the human decides, not the loop.

## Variant phrasings
### agent retries sqlmap dump timeout loop
The loop phrasing.
### sqlmap dump times out agent starts over
The checkpoint phrasing.
### agent never finishes sqlmap dump
The symptom phrasing.

Compatibility: harness retry logic plus sqlmap 1.x session handling.

## Why it happens
Full-database dumps are the longest single sqlmap operation, and time-based techniques make them slower still. An agent with no checkpointing treats each timeout as a fresh start, so the same multi-hour attempt restarts forever and never finishes.

## Edge cases / pitfalls
- Resuming a session against an app whose data changed mid-engagement can mix old and new rows. Note the resume in the report.
- Per-table dumps still need the agreed request rate: narrower scope does not authorize faster requests.
- A dump that times out because a defensive control started blocking looks identical to a slow dump. Check for new blocks before the third attempt.
- Prioritize tables with the tester before dumping; an agent choosing its own dump order wastes the time budget on low-value tables.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_MnPL-rM4a9wzaRQ8_rShAg