You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
F: track the production git push's process group across a crash #112
From the #103 review (PR #110). setUpRunner builds the production GitBranchPusher without onProcessGroup. A normal shutdown aborts the publish and awaits the git push. But if the codeboost process crashes, or is killed, while git push or git ls-remote runs, nothing records that process group. The next start then cannot find it, stop it, or report it.
Ask and execute preparations already record their process group so recovery can handle it (preparation_pgid). A push that outlives its process can move the task branch after startup recovery has run, and then the publish's recorded state is stale.
Needed
Record the push's process group durably before the push starts. Clear it once the push settles.
At startup recovery, refuse to start while a recorded push process group is still alive, the same way preparations are handled.
Alternatively, show that a surviving push is harmless. Its lease pins the branch value it read, and a later publish reads the branch again. In that case, document it and close this issue.
Tests
A crash during the push, simulated by a recorded process group that is still alive: startup refuses, with a removal command.
The same group, gone: startup goes on, and the publish finishes.
Decision (2026-10-03): resolve #112 by showing that a leftover push is harmless, and documenting why. Nothing will record or stop its process group. Implemented in PR #116, which is stacked on #110.
A git push left running by a crashed codeboost is leased to the branch value its own run read, so it can land only while the branch still holds that value:
Lands before a newer publish reads the branch: the newer publish reads it as codeboost's commit.
Lands between that read and its push: the newer push is refused as stale, and the next publish moves on.
Lands after the newer publish moved the branch: the leftover push is refused.
Tests in PR #116 replay the pusher's own push arguments against a real bare remote in each of these three orders.
One documented exception: the lease compares the branch's current value, not its history. If the branch returns to exactly the value the run read (a person moves it back, or the same commit is pushed again), the leftover lands. It can only put back a codeboost commit, and the next publish refreshes the PR.
The gh calls are outside this argument. Their effects are recovered by their markers: a lost opening, an update in flight, a close's read by number.
Activity
mchwang commentedon Oct 4, 2026
Decision (2026-10-03): resolve #112 by showing that a leftover push is harmless, and documenting why. Nothing will record or stop its process group. Implemented in PR #116, which is stacked on #110.
A
git pushleft running by a crashed codeboost is leased to the branch value its own run read, so it can land only while the branch still holds that value:Tests in PR #116 replay the pusher's own push arguments against a real bare remote in each of these three orders.
One documented exception: the lease compares the branch's current value, not its history. If the branch returns to exactly the value the run read (a person moves it back, or the same commit is pushed again), the leftover lands. It can only put back a codeboost commit, and the next publish refreshes the PR.
The
ghcalls are outside this argument. Their effects are recovered by their markers: a lost opening, an update in flight, a close's read by number.This closes when PR #116 reaches
main.D: document and test a leftover push recreating a deleted branch (#112)
D: show a push left running by a crash is harmless; document it (#112) (