mirror of
https://github.com/Ed1s0nZ/CyberStrikeAI.git
synced 2026-10-20 06:27:53 +02:00
Sycun
22a069849c
Reported from the live installation: after opening 系统设置 → 一键更新 (the automatic check runs) the 保存更新源 button silently stopped working — a click produced no request at all and the server log never saw a POST. Root cause: the busy flag is a render input — it stamps `disabled` + `data-state-disabled` on the action buttons — but the console only ever re-rendered *while* busy. checkForUpdates (including the automatic one) renders on entry and again when the response lands, and withUpdateBusy never rendered once the flag cleared, so the last render left the source-save button disabled for good. The carrier makes it permanent: data-state-disabled tells the platform's permission gate not to re-enable the element either. Measured in a browser after the auto-check: the DOM carried `disabled data-state-disabled="true"` while updateBusy was already false. Fix: withUpdateBusy now renders symmetrically — once on entry (the form visibly locks while an action is in flight) and once after the flag clears (usable again, button re-enabled) — skipping the exit render only when the restart watchdog owns the view. The transient error banner stops being an injected div and becomes state (updateActionError) rendered by renderUpdateConsole, so the exit render cannot wipe it; it clears when a new action starts or the console is re-entered. Tests: the regression follows the operator's exact chain — deferred automatic check → the form must be enabled again → clear the address → save must reach the server — plus a second-save check; the first fails on the old code on the disabled markup. Verified end to end in a real browser against a scratch installation: the render trace reads entry(busy)→response(busy)→exit(idle), and both saves (set and clear) hit the API and land in config.yaml.
