agent's VM snapshot revert crashed and left the sandbox in a dirty state, test failed

TL;DR

A revert that crashes mid-operation leaves a VM between states: disks partially rolled back, snapshot files inconsistent, and the next test inheriting the mess. Stop trusting reverts for reset in the harness: recreate test VMs from a template or golden image per run where feasible, add a pre-test state verification that rebuilds anything suspect, and make cleanup run even when a test crashes.

agent's VM snapshot revert crashed and left the sandbox in a dirty state, test failed

Use this when

• Tests fail in new ways after one revert crash, on a VM that previously passed.
• Snapshot files or VM configuration look inconsistent after the crash.
• Manual rebuild of the VM makes the mystery failures vanish.

Not for this skill when

• The production hypervisor has revert issues. Different estate and risk profile.
• Tests themselves corrupt the VM during a run and expect revert to fix it. That works until the revert is the thing that breaks.

Steps

1. Quarantine the dirty VM and capture its state and logs before rebuilding. Verify: evidence of the crash state is preserved
2. Change the harness reset strategy to redeploy from template or golden image instead of reverting snapshots. Verify: a test run uses a freshly deployed VM
3. Add a pre-test verification of VM state: disks attached as expected, no leftover snapshots, guest responsive. Verify: a deliberately dirtied VM is caught and rebuilt
4. Ensure cleanup and rebuild run in a finally-style path even when tests crash. Verify: a forced test crash still leaves a clean sandbox
5. Run the full test set twice back to back. Verify: both runs start from verified clean state and pass

Variant phrasings

vm revert crashed dirty sandbox rebuild template

The rebuild phrasing.

sandbox state corrupted failed revert cleanup

The cleanup variant.

test environment not reset between runs agent

The reset wording.

Compatibility: Agent test harnesses on VMware and Hyper-V sandboxes using snapshot revert or template redeploy reset strategies.

Why it happens

Revert feels like a free reset button, but it is itself a storage operation that can fail halfway, and its failure mode is silent state corruption rather than a clean error. Harnesses built on revert inherit that fragility at the worst moment, right between tests, where it contaminates the next result. Template redeploy trades a little time for a reset that is boring and dependable.

Edge cases / pitfalls

• Golden images need patching discipline or tests drift from production reality. Version them.
• If revert must stay for speed, verify the revert result before trusting the VM. Trust but verify applies literally here.
• Track sandbox rebuilds per week. A rising count signals an underlying platform problem.

Provenance

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