Loading challenge...
Trace Forensics
Diagnose a deterministically-seedable flaky flow from its trace instead of hitting rerun
What you will learn
- Diagnose a failure from a trace/video/network log instead of blindly re-running a flaky test
- Use a deterministic seed so a "flaky" failure reproduces identically and becomes debuggable
- Assert on stable step attributes (data-step, data-outcome) and inspect network responses, not console noise
Trace Forensics — Read the Failure, Don't Re-Run It
A four-step flow whose failure is deterministically seedable, so you practice diagnosing from the trace instead of hitting rerun
Each step calls /api/lab/trace. A step fails when its seeded roll falls under the flake rate, so the same seed reproduces the same failure every run — exactly the property that makes a flake diagnosable from a trace.
Flake rate: 0.3 · seed: default — set ?flake=0 for a green run or ?flake=1 to force the failure.
Run the Flow
Start the flow and read the per-step trace below
Testing Tips
Automation hints
- ✓ Run with
?flake=0for a deterministic green flow; assert#flow-result[data-outcome="success"] - ✓ The same
?seed=reproduces the same failing step — capture a Playwright trace (--trace on) and read which step 500'd instead of re-running - ✓ Each step row exposes
[data-step]+data-ok— assert on the attribute, and read network responses in the trace, not console output - ✓ Reading a trace/video/network log to find the failing step is the junior-vs-senior CI skill this lab drills
