Repository navigation
Apply and rebuild silently does nothing while the dev server is running #262
Description
What happens
With the dev server running, clicking Apply and rebuild on a patch or PR does nothing useful. The apply panel stays exactly as it was, and the only feedback is a single line in the terminal:
A command is already running. Press Ctrl+C to stop it.
Nothing is surfaced in the UI, so it reads as the button being broken rather than as a state you need to leave first.
Why
The terminal tracks one "a command is running" flag. Starting the dev server sets that flag and keeps it set for the whole life of the watcher (grunt _watch). The apply handler refuses to run while the flag is set and bails with the terminal message — but the Apply and rebuild button is never disabled for that state, so it stays clickable and gives no visible reason for doing nothing.
The Update to latest trunk button already handles the same situation correctly: it disables while the dev server is active and shows a "Stop the dev server before updating" tooltip. The apply action just never got the same guard.
Root cause
src/renderer/index.jsx— the Apply and rebuild button disables only on the update/install/build states, not on the dev-server-active state.src/renderer/index.jsx—runApplyguards on the terminal's running flag and writes the "already running" line without surfacing anything in the panel.src/renderer/index.jsx— the dev server sets that flag for its full lifetime, so it is true the entire time the watcher runs.
The same missing guard applies to the revert path and the per-PR "Apply…" buttons in the linked-PR list, since they share the same flow.
Expected
While the dev server is running, the apply actions should make it obvious you can't apply yet — the same way the trunk update button does — instead of appearing clickable and silently failing.
Steps to reproduce
- Start the dev server.
- Open a Trac ticket, pick a linked PR, and preview it.
- Click Apply and rebuild.
- Nothing changes in the panel; the terminal prints "A command is already running."
Activity
juanmaguitar commentedon Aug 11, 2026
Same root cause as #247
This is a symptom of the watcher holding the single terminal "running" slot for its whole life. While the dev server is up, that slot is taken, so apply is refused — the "A command is already running" line comes from that guard.
The preferred fix is not "stop the server so apply can run." For a patch that only touches
src/, the running watcher already rebuilds the change, so the standalone build the apply flow forces is redundant. The real fix is to decouple the watcher from the terminal slot — see the design proposal in #247 (give the watcher its own tab). Once that lands, this case stops being blocked on its own.A stop-gap in the meantime: disable the Apply and rebuild button while the dev server is active and explain why, the same way Update to latest trunk already does — so the action is not silently refused. The same guard is missing on the revert path and the per-PR "Apply…" buttons, which share the flow.
Depends on / tracked by #247.
Apply and update lean on the running build watch (#262)
Decouple the build watcher from the dev server, with its own control (#…
Apply and update lean on the running build watch (#262)
Apply and update lean on the running build watch (#262) (#273)
Bring the guide back in line with the app before 1.0 (#297)
[Fix] Hold the dev-server start in a tested queue, and treat a rebuil…
[Fix] Wait for Gutenberg's watcher to finish its first build before t…
[Add] Say on screen while the build watch is still rebuilding or comp…
[Fix] Let the resumed build watch do the one rebuild after a Gutenber…
[Fix] Let a work-item switch leave the build watch running instead of…
[Fix] Let a work-item switch leave the build watch running instead of…
[Fix] Let a work-item switch leave the build watch running instead of…