Summary
In the three working May 2026 replays, 18–24% of pipeline frames are rejected by the frame validator after successful parsing. The parser accepts 0 frames as rejected, so this is a pipeline-level validation failure, not a format issue.
Data
| File |
Parsed frames |
Pipeline processed |
Pipeline invalid |
Rejection rate |
rec_2026-05-01_14-27-52.echoreplay |
153,257 |
29,353 |
7,097 |
24.2% |
rec_2026-05-01_14-58-25.echoreplay |
66,726 |
11,121 |
2,079 |
18.7% |
rec_2026-05-01_15-10-00.echoreplay |
74,242 |
12,430 |
2,930 |
23.6% |
Note: "Parsed frames" = player-frames (one per player per session snapshot). "Pipeline processed/invalid" = per-frame-index counts. The ratio difference is expected (multiple players per frame index).
Shadow deployment stop condition
The shadow deployment guide specifies a stop condition at >20% frame rejection rate. Two of the three files exceed this threshold.
Likely rejection reasons (from internal/pipeline/validator.go)
The validator rejects frames for:
zero position for player %s — position is [0,0,0]
NaN/Inf position for player %s
dt %.4f out of range — DeltaTime outside [minDt*0.5, maxDt*2.5]
position out of arena bounds — outside arena extents (X: ±12.5m, Y: ±12.5m, Z: ±82m)
The most likely cause is non-active game phases (round_start, score, pre_match, post_match) where players teleport or respawn at [0,0,0], triggering the zero-position check. The pipeline already skips detection during non-active phases but still runs validation, so these frames count as "invalid" rather than "skipped."
However: the shadow guide stop condition is based on the rejection rate being a sign of adapter breakage, not phase transitions. If the 24% is entirely from phase transitions, the stop condition threshold may need to be raised or the counting logic changed to exclude non-active phase frames from the invalid count.
Needed
- Log the rejection reason per frame (currently the reason is returned as an error string but not counted by category)
- Determine what fraction of invalid frames are zero-position vs out-of-bounds vs dt-out-of-range
- If the majority are phase-transition zero-positions, adjust the stop condition or exclude them from the count
Summary
In the three working May 2026 replays, 18–24% of pipeline frames are rejected by the frame validator after successful parsing. The parser accepts 0 frames as rejected, so this is a pipeline-level validation failure, not a format issue.
Data
rec_2026-05-01_14-27-52.echoreplayrec_2026-05-01_14-58-25.echoreplayrec_2026-05-01_15-10-00.echoreplayNote: "Parsed frames" = player-frames (one per player per session snapshot). "Pipeline processed/invalid" = per-frame-index counts. The ratio difference is expected (multiple players per frame index).
Shadow deployment stop condition
The shadow deployment guide specifies a stop condition at >20% frame rejection rate. Two of the three files exceed this threshold.
Likely rejection reasons (from
internal/pipeline/validator.go)The validator rejects frames for:
zero position for player %s— position is[0,0,0]NaN/Inf position for player %sdt %.4f out of range— DeltaTime outside[minDt*0.5, maxDt*2.5]position out of arena bounds— outside arena extents (X: ±12.5m, Y: ±12.5m, Z: ±82m)The most likely cause is non-active game phases (round_start, score, pre_match, post_match) where players teleport or respawn at
[0,0,0], triggering the zero-position check. The pipeline already skips detection during non-active phases but still runs validation, so these frames count as "invalid" rather than "skipped."However: the shadow guide stop condition is based on the rejection rate being a sign of adapter breakage, not phase transitions. If the 24% is entirely from phase transitions, the stop condition threshold may need to be raised or the counting logic changed to exclude non-active phase frames from the invalid count.
Needed