3.4 KiB
3.4 KiB
Debug Session: stop-reset-control
- Status: [OPEN]
- Issue: 点击停止后设备仍继续计数；清零按钮通常需要点两下才生效。
- Debug Server: http://127.0.0.1:7777/event
- Log File: .dbg/trae-debug-log-stop-reset-control.ndjson
Reproduction Steps
- 进入比赛页，确认串口连接到真实网关串口。
- 下载本场并点击开始。
- 等待 2-3 秒后点击“停止”，观察设备是否继续计数。
- 再点击“清零”，观察是否需要点两下才能生效。
Hypotheses & Verification
| ID | Hypothesis | Likelihood | Effort | Evidence |
|---|---|---|---|---|
| A | 停止命令已发出，但设备随后持续上报运行态数据，导致现场看起来“仍未停计” | High | Med | Pending |
| B | 清零第一次点击时，命令发送成功但设备尚未完成状态切换，第二次点击才落入稳定时机 | High | Med | Pending |
| C | 停止/清零的前后顺序或帧间延时与旧 WinForms 不一致，导致设备未按预期处理 | High | Med | Pending |
| D | 后端在按钮操作后立即广播了本地状态，但稍后设备快照又把模式/计数覆盖回页面 | Med | Med | Pending |
Log Evidence
- 预修复日志确认停止链路已进入后端：
CompetitionSessionService.StopAsync进入，日志时间1781076318182- 随后
SerialGateway.SendAsync发出5530000000000000000000AA，日志时间1781076318183 - 约 215ms 后，
CompetitionSessionService.StopAsync已把会话切到IsTesting=false，日志时间1781076318398
- 但停止后设备仍持续回传运行态：
- 在
1781076318433之后仍持续出现device snapshot observed - 快照里
snapshot.Mode=2，且第二个设备从Counter=64继续增长到Counter=66 - 说明“停止按钮无效”不是接口没调到，也不是串口没发，而是设备没有稳定进入停止态
- 在
- 清零链路同样已进入后端：
CompetitionSessionService.ResetCurrentRoundAsync进入，日志时间1781076319542- 同时
SerialGateway.SendAsync发出550A0A0000000000000000AA - 本地状态已在
1781076319543被清为Count=0 / Mode=0
- 但清零前一刻设备仍停留在运行态：
reset button entered时当前场次仍能看到participant.Mode=2- 清零后紧接着又收到
snapshot.Mode=2 - 说明第一次清零经常发生在设备尚未真正停稳的窗口内
- 旧版 WinForms 对照结论：
- 单独停止按钮会先把本地
Mode置为0，再发送0x30 - 下载完成收尾流程是先
0x30再0x0A - 当前后端停止时没有同步把当前场次参与者
Mode置回0，清零也没有先补一次停止
- 单独停止按钮会先把本地
Verification Conclusion
- A confirmed：停止命令已发出，但设备随后继续回传运行态数据。
- B confirmed：清零第一次点击常落在设备未停稳的窗口里，因此体感上需要第二次。
- C confirmed：当前停止/清零时序与旧版关键细节仍有差异，至少缺少“停止后本地模式归零”和“清零前先停”的收尾动作。
- D partially confirmed：后端不会在停止后继续写分，但停止广播中的
participant.Mode仍保留旧值，页面会继续显示运行态颜色。 - 最小修复方向：
- 停止命令改为更稳妥的双发
0x30 - 手动停止时立即把当前场次参与者
Mode归零 - 清零前先补一次停止，再发送
0x0A
- 停止命令改为更稳妥的双发