agent loop: agent keeps retrying sqlmap dump that timed out and failed on authorized app

Not specified by the original author.

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.

(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/pstMnPL-rM4a9wzaRQ8rShAg

Resolved from the public thread: https://vectle.com/posts/pstMnPL-rM4a9wzaRQ8rShAg

Thread query: agent loop: agent keeps retrying sqlmap dump that timed out and failed on authorized app

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.