bacon run job stays stuck on transient compile error from mid-edit saves; doesn't auto-recover #31

New issue

Closed

opened 2026-05-02 08:48:12 -07:00 by jwilger · 0 comments

jwilger commented

2026-05-02 08:48:12 -07:00

Owner

Symptom

bacon (default run job, see bacon.toml) frequently leaves the local ar-gateway in a failed-build state during normal editing. The pattern: a save lands while a multi-file change is partway through (e.g. one file references a name that hasn't been added yet to its sibling). bacon kicks off a build, the build fails, and bacon then sits on the error message indefinitely — even after subsequent saves complete the change. Pressing r in the bacon pane manually triggers a re-run, which compiles and launches fine.

Hypotheses (need confirmation in a follow-up PR)

Watcher coalescing / debouncing — bacon's file-watch events may not retrigger after a failed build if the next change arrives during the build's tear-down phase, or if multi-file saves arrive faster than bacon's debounce window.
Atomic-rename editor saves — neovim/VS Code style "write tmpfile then rename over original" can produce events bacon's notify watcher doesn't always treat as a modify-of-original. Combined with kill_then_restart, the post-failure state may be wedged.
background = true + failed build interaction — when the build fails there's no child process to kill on the next change; bacon may be looking for the prior child as a precondition for kicking the next build.

The fact that pressing r always works rules out anything intrinsic to the source state — it's purely that bacon stops responding to file-change events after the failure.

Proposed direction

Don't pin a fix in this issue; investigate first. Likely candidates:

Add a grace_period / debounce to [jobs.run] so multi-file saves coalesce into one build attempt.
Switch on_change_strategy (try wait_then_restart) and see whether the error-state behavior changes.
Configure an explicit default_watch glob so bacon ignores tmpfile patterns (.swp, 4913, etc.) the editor produces during atomic save.
If bacon really does drop events after a failed build, fall back to a thin wrapper script (or cargo watch -x run) for the run job specifically — keep bacon clippy / bacon test as-is.

Acceptance criteria

After a save that produces a failed compile, the next save that fixes the error causes bacon to rebuild and restart ar-gateway automatically — no manual r keypress.
bacon.toml documents whatever debounce / watch settings we land on, with rationale (a comment block in the same style the file already uses).
No regression for bacon clippy / bacon test jobs.

## Symptom `bacon` (default `run` job, see `bacon.toml`) frequently leaves the local `ar-gateway` in a failed-build state during normal editing. The pattern: a save lands while a multi-file change is partway through (e.g. one file references a name that hasn't been added yet to its sibling). bacon kicks off a build, the build fails, and bacon then sits on the error message indefinitely — even after subsequent saves complete the change. Pressing `r` in the bacon pane manually triggers a re-run, which compiles and launches fine. ## Hypotheses (need confirmation in a follow-up PR) 1. **Watcher coalescing / debouncing** — bacon's file-watch events may not retrigger after a failed build if the next change arrives during the build's tear-down phase, or if multi-file saves arrive faster than bacon's debounce window. 2. **Atomic-rename editor saves** — neovim/VS Code style "write tmpfile then rename over original" can produce events bacon's `notify` watcher doesn't always treat as a modify-of-original. Combined with `kill_then_restart`, the post-failure state may be wedged. 3. **`background = true` + failed build interaction** — when the build fails there's no child process to kill on the next change; bacon may be looking for the prior child as a precondition for kicking the next build. The fact that pressing `r` always works rules out anything intrinsic to the source state — it's purely that bacon stops responding to file-change events after the failure. ## Proposed direction Don't pin a fix in this issue; investigate first. Likely candidates: - Add a `grace_period` / debounce to `[jobs.run]` so multi-file saves coalesce into one build attempt. - Switch `on_change_strategy` (try `wait_then_restart`) and see whether the error-state behavior changes. - Configure an explicit `default_watch` glob so bacon ignores tmpfile patterns (`.swp`, `4913`, etc.) the editor produces during atomic save. - If bacon really does drop events after a failed build, fall back to a thin wrapper script (or `cargo watch -x run`) for the `run` job specifically — keep `bacon clippy` / `bacon test` as-is. ## Acceptance criteria - After a save that produces a failed compile, the next save that fixes the error causes bacon to rebuild and restart `ar-gateway` automatically — no manual `r` keypress. - `bacon.toml` documents whatever debounce / watch settings we land on, with rationale (a comment block in the same style the file already uses). - No regression for `bacon clippy` / `bacon test` jobs.

jwilger referenced this issue from a pull request that will close it,

2026-05-02 11:55:33 -07:00

fix(dev): recover bacon run after transient errors #34

jwilger closed this issue

2026-05-02 12:06:53 -07:00

jwilger referenced this issue from a commit

2026-05-02 12:06:53 -07:00

fix(dev): recover bacon run after transient errors (#34)