fix(watcher): a push during a running build is no longer lost #57

2026-09-12T20:16:52+02:00

mi commented

2026-09-12 20:16:52 +02:00

A commit that landed while a build of the same pool was still PENDING or
RUNNING was skipped -- and then never built. The watcher read a branch's
dueness from its lagging local ref, but fast-forwarded that very ref at the
end of the same cycle, so from the next cycle on the skipped branch no longer
looked changed and the "later cycle" its doc comment promised never came. The
branch stayed behind origin until another push arrived or recoverOnStartup
healed it at the next restart.

The dueness is now remembered where it is decided: RepoWatch.deferredBranches
holds the branches startBuildIfDue refused for a busy pool, and the next
enqueue takes that set over and reconsiders them alongside the changed ones.
A branch still waiting is put back by that same call, one gone from origin
yields no head commit and drops out -- so the memory clears itself.

WatcherTest covered only that other branches keep going while a build runs,
never the next cycle of the same branch; both the queue-behind case and the
forgetting of a vanished branch are covered now.

release 1.11.2

Co-Authored-By: Claude Opus 5 noreply@anthropic.com

A commit that landed while a build of the same pool was still PENDING or RUNNING was skipped -- and then never built. The watcher read a branch's dueness from its lagging local ref, but fast-forwarded that very ref at the end of the same cycle, so from the next cycle on the skipped branch no longer looked changed and the "later cycle" its doc comment promised never came. The branch stayed behind origin until another push arrived or recoverOnStartup healed it at the next restart. The dueness is now remembered where it is decided: RepoWatch.deferredBranches holds the branches startBuildIfDue refused for a busy pool, and the next enqueue takes that set over and reconsiders them alongside the changed ones. A branch still waiting is put back by that same call, one gone from origin yields no head commit and drops out -- so the memory clears itself. WatcherTest covered only that *other* branches keep going while a build runs, never the next cycle of the same branch; both the queue-behind case and the forgetting of a vanished branch are covered now. release 1.11.2 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

mi added 1 commit 2026-09-12 20:16:53 +02:00

fix(watcher): a push during a running build is no longer lost

werkator build succeeded after 01:55

Details

abd95fac7a

A commit that landed while a build of the same pool was still PENDING or
RUNNING was skipped -- and then never built. The watcher read a branch's
dueness from its lagging local ref, but fast-forwarded that very ref at the
end of the same cycle, so from the next cycle on the skipped branch no longer
looked changed and the "later cycle" its doc comment promised never came. The
branch stayed behind origin until another push arrived or recoverOnStartup
healed it at the next restart.

The dueness is now remembered where it is decided: RepoWatch.deferredBranches
holds the branches startBuildIfDue refused for a busy pool, and the next
enqueue takes that set over and reconsiders them alongside the changed ones.
A branch still waiting is put back by that same call, one gone from origin
yields no head commit and drops out -- so the memory clears itself.

WatcherTest covered only that *other* branches keep going while a build runs,
never the next cycle of the same branch; both the queue-behind case and the
forgetting of a vanished branch are covered now.

release 1.11.2

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

mi merged commit 4323527699 into main

2026-09-12 20:17:21 +02:00

mi deleted branch fix/watcher-queue-behind-lost

2026-09-12 20:17:21 +02:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: mi/werkator#57