What problem does it solve?
Trace replay diagnoses why the notification consumer grouped, edited, redirected, or “fell through” into a new message by reconstructing prior decisions from recorded JSONL traces.
Core Features & Use Cases
- Replay notification queue history: Reconstructs what happened to a specific dedup key, commit SHA, room, activityId, event, kind, or time window by replaying
.logs/notif-trace-YYYY-MM-DD.jsonl.
- Explain decision outcomes: Interprets trace
kind values such as recent_lookup, recent_saved, edit_skipped_no_convref, edit_fell_through, announce_redirect, and batch-related kinds to determine the likely root cause.
- Supports multiple investigation modes: Uses
--mode timeline for chronological story, --mode grouped for activity lifecycle, and --mode raw for field-level inspection when timeline/grouped is insufficient.
Quick Start
Ask the user for the approximate date/time and dedup anchor (dedup key, commit SHA, room, or activityId), confirm the matching trace file exists in .logs/, then run the replay in timeline mode for that window to identify the key kind that caused the behavior.