WARN [recovery]: Data verification failed – possible test flakiness when source maps are not reapplied to restored stack traces

Goal

Determine whether Karma should reapply source maps to restored error stack traces after an abnormal termination recovery, ensuring that debug messages point to original source code rather than transformed locations.

Constraints and uncertainty

Karma currently re‑uses the transformed locations from the failed run when loading the temporary JSON file, which can produce misleading stack traces. The recovery mechanism does not specify source‑map handling, leaving the behavior undefined and potentially inconsistent across runs. It is unclear how re‑mapping would affect performance, compatibility with missing or outdated source maps, and existing workflows that rely on the current output.

Should Karma automatically reapply source maps to restored stack traces? What performance overhead would source‑map re‑application introduce during recovery? How should Karma behave when source maps are unavailable or stale?