Partial snapshot state after an interrupted Vitest update run

Recovery from Partial Snapshot States

Vitest does not provide a built-in atomic update mechanism or a native rollback command for snapshots. Because snapshot files are written to disk sequentially as tests complete, an interrupted process (such as a SIGKILL or a system crash) during a --update run will leave the __snapshots__ directory in an inconsistent state.

Likely Behavior and Impact

Based on Vitest v1.x behavior, the following outcomes are expected after an interrupted update:

• Partial Writes: Files that were being written at the moment of interruption may be truncated or corrupted.
• Inconsistency: Some test files will have updated snapshots while others retain the previous versions, leading to a mismatch between the current code state and the snapshot baseline.
• Parse Failures: Partially written files typically cause parse errors or unexpected EOF (End Of File) failures during the next test run, as Vitest cannot deserialize the corrupted snapshot data.

Recommended Recovery Procedure

Since Vitest lacks an internal recovery tool, the recommended approach is to use your version control system (VCS) to restore the snapshot directory to the last known-good state before attempting a fresh update.

1. Revert snapshots to the last commit:

   git checkout HEAD -- **/ __snapshots__/*

2. Verify the current state: Run tests without the update flag to ensure the environment is stable.

   npx vitest run

3. Perform a clean update: Once the state is consistent, re-run the update process.

   npx vitest run --update

Assumptions and Constraints

This guidance assumes you are using Vitest v1.x and that your snapshots are tracked in a Git repository. If snapshots are not versioned, the only recovery option is to manually delete the __snapshots__ directory and regenerate them entirely, though this risks introducing regressions if the current code contains unintended changes.

Diagnostic Detail Required: Are you seeing specific SyntaxError or Unexpected token messages when running tests after the interruption? If so, this confirms file corruption rather than simple version mismatch.