Skip to content

F: track the production git push's process group across a crash #112

Closed

Description

@mchwang

Why

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.

🤖 Generated with Claude Code

Activity

  1. mchwang commented on Oct 4, 2026

    @mchwang
    ContributorAuthor

    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.

    This closes when PR #116 reaches main.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions