Repository navigation
fix(GeneralBattle): retry prepare click after battle_before timeout - #1801
Conversation
![sourcery-ai[bot]](https://avatars.githubusercontent.com/in/48477?s=60&v=4){kind=small}
Findings
Warning Firewall blocked 1 domainThe following domain was blocked by the firewall during workflow execution:
To allow these domains, add them to the network:
allowed:
- defaults
- "ab.chatgpt.com"See Network Configuration for more information.
|
Change Summary
Reconstructed Intent点击此处展开
Observed Constraints点击此处展开
Intent Alignment
Release Risk
Validation Gaps点击此处展开
Warning Firewall blocked 1 domainThe following domain was blocked by the firewall during workflow execution:
To allow these domains, add them to the network:
allowed:
- defaults
- "ab.chatgpt.com"See Network Configuration for more information.
|
|
感谢分析。针对 Intent Alignment 与 Release Risk 中的两点，补充核实结果： 1. 关于 execute_round 中无超时的 wait_until_appear(I_BACK_RED) 2. 关于"其他调用者多数忽略返回值" 3. 关于 3 秒窗口与动画时序 |
When the start-battle click (GB_PREPARE_HIGHLIGHT) is intercepted by the closing preset-panel animation, the battle never starts and battle_before returns False after its 5s timeout. run_general_battle then entered battle_wait's infinite loop waiting for a result screen that never appears - the script looks stuck until the user clicks start manually. Fix: after battle_before times out, re-check the screen for up to 3s: - still on the prepare screen -> click start battle once and wait for the battle to begin (click only once, then just poll - avoid repeated clicks during UI transition) - already in real battle -> continue normally - neither (abnormal state) -> log a warning and return False so callers handle it as a failed battle instead of waiting forever
57b825d to
65a6b73
Compare
|
已按建议修改完成： |
2 participants
Problem
In RealmRaid (and other battles using run_general_battle), the start-battle click (GB_PREPARE_HIGHLIGHT) can be intercepted by the closing preset-panel animation right after switching preset team, so the battle never starts. battle_before() returns False after its 5s timeout, but the return value was ignored and run_general_battle still entered battle_wait()'s infinite loop waiting for a result screen that never appears - the script looks stuck with no action until the user manually clicks start.
Reproduced in real logs: 14:23:15.236 start click missed, battle_before returned False at 14:23:15.8, then the script waited in battle_wait until the user manually started the battle (won at 14:23:33).
Fix
Keep the original logic untouched. After battle_before() times out, re-check the screen for up to 3s (retry_prepare_click):
Verification
Sourcery 摘要
在战斗开始前超时后重试启动普通战斗；当无法确认战斗状态时安全地中止。
Bug 修复：
Original summary in English
Sourcery 总结
让普通战斗能够从未成功点击开始按钮的情况中恢复，并在无法确认战斗状态时安全退出。
错误修复：
Original summary in English
Summary by Sourcery
Make general battles recover from missed start clicks and fail safely when the battle state cannot be confirmed.
Bug Fixes: