FIRST-Tech-Challenge / FIRST-Tech-Challenge/scorekeeper
Match Replays mess up cycle time report
- Dominant language
- No language data
- Stars
- 110
- Forks
- 26
- PR merge metrics
- No merged PRs in 30d
Description
**Describe the bug**
(If this is considered expected behavior, please consider this a feature request to either change the expected behavior or have a feature toggle)
At USWAMVSQ1 we replayed match 10 at the end of the qualification phase. After the match replay was posted, the Cycle Time Report changed the "start" of Q10 to 4:27pm (from the initial play around 1:25pm), changed the cycle time for Q9 to "187m 40s" (from the initial play somewhere around 5 minutes), and cleared out the cycle time for Q10.
**To Reproduce**
Steps to reproduce the behavior:
1. Play matches 1 to 5
2. Observe the cycle time for matches 1 and 2
3. Go back and replay match 2
4. Go to the cycle time report
5. Observe Match 2 "start time" changes to the replay start time, Match 1 "cycle time" becomes a large time, Match 2 "cycle time" becomes blank
**Expected behavior**
Either:
1. Match and Average Cycle Time should remain as-was from the initial play
* or, add more logic so replays that happen before other matches do update like this, but ignore updates if other matches were played between
2. Leave the current table-update behavior, but ignore it in the average cycle calculation
3. Add a new row for the replayed match in the appropriate time slot? (in this case, Q10-2 goes where a hypothetical Q41 would go)
In this case, I would expect the cycle time "excluding breaks" to be somewhere in the neighborhood of 5m 30s, not 9m 59s.
**Screenshots**
**Device (please complete the following information):**
- OS: Server (some flavor of linux), client (any OS - Windows, MacOS, iPadOS)
- Browser Chrome, iPad Safari, Windows Firefox
- Version [e.g. 22]
**Additional context**
Contributor guide
No contributing guide indexed for this repository
Assessment
This issue has not been assessed yet.