agent loop detected: re-executed a cell that deletes the source csv it reads from, restore failed
Breaks an agent loop that re-executes a cell deleting its own input CSV: make destructive cells guarded and non-reentrant. For agent builders. Never silently deleting user data is the framing rule.
TL;DR
A cell that deletes the CSV it reads from will succeed once and then fail forever, and an agent that re-runs it loops on a file that no longer exists. This is a data-safety bug first and a loop bug second: destructive operations must be guarded (check the file exists, refuse to delete inputs, write to a separate output path). Fix the cell so re-execution is safe, then fix the agent to stop retrying destructive failures blindly.
agent loop detected: re-executed a cell that deletes the source csv it reads from, restore failedUse this when
- An agent re-runs a cell that deletes or overwrites its own input.
- The source file is gone and cannot be restored.
- The loop is: run, file missing, retry, file still missing.
Not for this skill when
- The file was deleted by a human. Restore from backup or version control.
- The cell fails for other reasons. Debug those directly.
Steps
- Stop the agent immediately to prevent further damage. Verify: no more executions are running.
- Assess the data loss: check backups, version control, or the source system for the CSV. Verify: you know whether it is recoverable.
- Rewrite the cell: never delete inputs; write outputs to a separate path; guard with existence checks. Verify: re-running the cell is safe.
- Add the agent rule: destructive operations require explicit confirmation and are never retried automatically. Verify: the policy is in the agent's runbook.
- Restore the data from backup and re-run. Verify: the run completes without touching the source.
Variant phrasings
agent deleted input file loop
Short form. Guard destructive cells.
cell deletes its own input csv
The bug phrasing. Separate input and output paths.
agent re-execution data loss
The safety phrasing. Never auto-retry destructive ops.
Compatibility: Any notebook runner. The guard pattern is language-agnostic.
Why it happens
Notebooks mix exploration with file operations, and a cleanup line that made sense once (remove the raw file after processing) becomes a landmine under an agent that re-executes freely. The first run deletes the input; every later run fails on the missing file; the agent retries because retry is its hammer. The deeper failure is that nothing marked the operation as destructive and non-retryable.
Edge cases / pitfalls
- This vertical's framing rule applies: agents must never silently delete user data. Deletion needs explicit user confirmation.
- Backups are the only real safety net. Version the inputs or keep the raw data immutable.
- A 'restore failed' means the damage is done. The lesson goes into the runbook, not just the cell.
- Audit other cells for the same pattern (overwrite-in-place, delete-after-read). Fix them all.
Provenance
Resolved from the public thread: https://vectle.com/posts/pstUQzHW6inYIfqMuay2DFjQ