Contention Trace Replay¶
Diagnostic tool — instantiates Progress-Guarded Livelock Disruption
Captures a real contention episode as an ordered event trace and replays it deterministically, so a livelock can be reproduced on demand, dissected, and reduced to a reusable signature.
Livelocks are maddening to debug because they depend on timing: by the time you attach a debugger, the interleaving that caused the loop is gone. Contention Trace Replay records the interleaved events of a contention episode — every perception, decision, and action of the coupled actors, in order — and replays them deterministically, turning a fleeting, unrepeatable stuck-loop into an artifact you can single-step, dissect, and hand to a colleague. Its distinguishing move is reproduction-then-cataloguing: where a live monitor detects a loop as it happens, replay recreates one off the live system and distils it into a signature future episodes can be matched against.
Example¶
Two automated guided vehicles meet in a one-lane warehouse aisle. Each detects the other, both step aside the same direction, both re-approach, both step aside again — a "corridor dance" that only manifests under a particular timing and so is nearly impossible to catch live. Contention Trace Replay logs every sensor read, planner decision, and motion command from both robots with timestamps and ordering. Replayed deterministically in the simulator, the dance reproduces every time. Engineers single-step it and can finally see that both robots log continuous activity — sensing, planning, moving — while net displacement toward their goals stays at zero. They reduce the episode to a signature: symmetric avoid-avoid oscillation, period ≈ 2 s, mutual lateral mirroring, and register it so the fleet monitor can name the pattern the instant it recurs.
How it works¶
- Capture the interleaving. An ordered, timestamped event log of the coupled actors, detailed enough to reproduce the interleavings that matter.
- Replay deterministically. Re-execute the trace so a nondeterministic, timing-dependent bug becomes reliably reproducible — the same technique as deterministic record-and-replay debugging.[1]
- Dissect activity vs. progress. On replay, overlay raw activity against the goal measure so "lots of events, zero progress" is legible frame by frame.
- Extract and register a signature. Reduce the episode to a compact fingerprint and file it, building an institutional catalogue of contention patterns.
Tuning parameters¶
- Capture fidelity — how much event detail is logged. More gives faithful replay but is heavy and can perturb the very timing you are chasing.
- Determinism level — full deterministic replay versus statistical reproduction. Full replay costs more but recreates rare interleavings that statistics miss.
- Signature abstraction — how general the extracted fingerprint is. Too specific and it won't match variants; too general and it false-matches unrelated episodes.
- Replay environment fidelity — simulator versus shadow-production. Higher fidelity reproduces more behaviours but costs setup.
- Registry scope — how many signatures to retain and match against, trading recall for noise.
When it helps, and when it misleads¶
Its strength is turning an intermittent, timing-dependent livelock into something reproducible and shareable: "we think it loops" becomes a stepped-through fact, and the signature registry becomes durable memory so a recurrence is recognised, not re-investigated from scratch.
Its failure modes come from the act of observing. Heavy capture perturbs timing and can mask the very race it is meant to expose — a heisenbug that vanishes under instrumentation. Replay reproduces the captured episode, which is not always the general failure. And signatures over-fit, either missing variants or crying wolf. The classic misuse is replaying a hand-picked trace to "confirm" a root cause chosen in advance. The discipline is to capture before forming the hypothesis, keep captures representative rather than curated, and treat a matched signature as evidence to check, not proof.
How it implements the components¶
Contention Trace Replay fills the reproduce-and-catalogue side of detection — distinct from a live cycle monitor:
activity_progress_separation— replaying the episode and overlaying activity against the goal measure makes busy-but-stuck concretely visible.cycle_signature_registry— reduces the episode to a fingerprint and registers it so future contention is matched, not re-diagnosed.
It does not detect the loop live or model the reciprocal joint state (non_progress_cycle_detector, coupled_actor_response_map, joint_state_progress_invariant — that's Joint-State Cycle Trace); and being a diagnostic, it applies no fix — symmetry, cooldown, and escalation belong to its intervention siblings.
Related¶
- Instantiates: Progress-Guarded Livelock Disruption — it supplies the reproducible episode and the signature the rest of the appraisal reasons over.
- Sibling mechanisms: Joint-State Cycle Trace · State-Machine Cycle Detection · Liveness Watchdog · Leader Election or Token Passing · Circuit Breaker and Cooldown
Editorial Notes¶
Form Classification¶
Form family: Experiment, Test & Rehearsal
Rationale: Captures a real contention episode as an ordered event trace and replays it deterministically, so a livelock can be reproduced on demand, dissected, and reduced to a reusable signature, making its operative form a bounded trial, probe, simulation, or adversarial exercise that generates evidence from performance.
Independent corroboration: The frozen evidence defines Contention Trace Replay as 'Captures a real contention episode as an ordered event trace and replays it deterministically, so a livelock can be reproduced on demand, dissected, and reduced to a reusable signature', so its operative form is Experiment, Test & Rehearsal.
Review outcome: Independent reviewer agreement; high confidence.
Origin Attribution¶
Primary origin: Computer Science & Software Engineering
Origin pattern: Single lineage
Present-day reach: Specialized
Rationale: Concurrent-systems debugging cohered deterministic record-and-replay of timing-sensitive interleavings to reproduce livelock and race failures off the live system.
Related originating lineages:
- Engineering & Design — Failure-analysis practice contributes reduction of a reproduced episode into a reusable fault signature.
Review resolution: Deterministic record-and-replay of concurrent interleavings is a recognizable computer-science debugging method; engineering failure analysis is a genuine supporting lineage.
Review outcome: Reconciled after independent review; high confidence.
Notes¶
The instrument perturbs the experiment: rich capture can shift timing enough to suppress the livelock it was meant to record. When a bug disappears under full-fidelity capture, that is itself a finding — the loop lives in the timing margin the instrumentation just erased — and argues for lighter, sampled capture or a shadow environment rather than heavier logging.
Draft — generated mechanism page.
References¶
[1] Ronsse, M., De Bosschere, K., & Chassin de Kergommeaux, J. "Execution Replay and Debugging". In Proceedings of the Fourth International Workshop on Automated Debugging (AADEBUG 2000), 5–18 (2000). Explains execution replay as recording a nondeterministic run so it can be replayed reproducibly for debugging. registry ↩