Menu.qml evaluateGuards() runs every when:, checked: and disabled: guard of the menu in one child process, guardProc.command = ["bash", "-lc", script]. Nothing puts a deadline on that process. While guardProc.running is true, each later evaluateGuards() call only sets guardsPending and returns. The batch exit then starts the deferred evaluation. One blocking guard expression keeps the whole batch alive indefinitely. Examples are a wait on a lock, a slow probe or a hung device query. No later evaluation then starts. For the rest of the session the menu shows the last complete answer set. Rows stay checked, visible or dimmed for a state that no longer holds. A killed batch keeps the last complete set and does not adopt a half-read one. A when: hides a row only on an explicit false, so the failure shows stale rows, not hidden ones. pocs/47t8-guard-batch-no-deadline.sh reproduces the defect. It runs the real evaluateGuards() and guardProc handlers from Menu.qml with the real MenuModel.guardScript(). The test adds a guard that waits on a held lock. At 4s the batch still runs with zero exits, and a re-evaluation spawns nothing (guardsPending=true). A row's checked answer stays false after its state turns true. The control arm shows a healthy batch that lands its answers and refreshes after a state flip.

why this rating

Reproducer-confirmed

risk area

Availability