Skip to content

fix(processgroup): one undecidable group no longer hides the rest - #1236

Merged
markwang-obin merged 2 commits into
mainfrom
fix/reap-past-undecidable-group
Oct 29, 2026
Merged

markwang-obin merged 2 commits into
mainfrom
fix/reap-past-undecidable-group

Conversation

@markwang-obin

@markwang-obin markwang-obin commented Oct 29, 2026 •

Copy link
Copy Markdown
Contributor

Part A of #1233.

The problem. A registered process group whose boot identity Core can't decide (checkBootIdentity: same leader PID and start, different boot_id, which happens when an older Darwin agent recorded the clock-derived kern.boottime) is rightly kept without signaling. But:

Fix

  • PreviewManagedProcessGroups keeps going. A group whose ownership inspection fails, or isn't authenticated, is left out and named in the returned error with its recovery command (codefly recover process-group PGID --preview). Every other group is still listed. The error keeps its inspect registered group <pgid>: prefix, which TestReaperUsesOwnerInspectionForSupportedRecords relies on.
  • reconcileRegisteredGroup names the same recovery in its error. It already continued past a refused group.
  • codefly clear --dry-run prints the groups it could list, warns about the kept ones, carries on to the socket count, and then returns the error.
  • docs/orchestration.md: one sentence on how a kept group affects the others.

Classification: fix at the owner. Core's refusal is unchanged: a group whose identity can't be decided is still never signaled. Reused: Core's ListProcessGroups/InspectOwnership, and the existing codefly recover process-group workflow. No new mechanism.

Tests (written first)

TestAnUndecidableGroupIsKeptWithoutStoppingTheRest starts two real tracked groups in one workspace, then rewrites one record's leader and owner boot_id the way an older writer left it.

  • The preview lists only the healthy group, and its error names the undecidable one with codefly recover process-group <pgid>.
  • The stop stops the healthy group, leaves the undecidable one alive, and names its recovery.

TestClearDryRunReportsPastAnUndecidableGroup (cmd) covers clear's dry-run output: two real tracked groups (one recorded as an older agent left it) and one stale agent socket, under a temporary HOME and TMPDIR. The dry run:

  • logs the healthy group it would stop;
  • warns about the kept group, with codefly recover process-group <pgid>;
  • counts the stale socket;
  • returns the refusal;
  • signals neither group.

It fails with either half of the fix reverted: with main's cmd/clear.go nothing is logged, and with main's registered.go it logs count=0.

Against main, it fails with #1233's exact error ("inspect registered group …: incompatible boot identity for unchanged process start …") and an empty preview.

Also run: go test ./pkg/processgroup (all pass), go test ./cmd -run 'Clear|Recover', go vet, and golangci-lint run ./pkg/processgroup/... ./cmd/... (0 issues).

Not done here, and not verified

🤖 Generated with Claude Code

markwang-obin and others added 2 commits October 29, 2026 12:11
A registered group whose boot identity Core cannot decide (an older Darwin
agent's clock-derived boot id) is rightly kept without signaling. But the
preview aborted on the first such group, so `codefly clear --dry-run`
listed nothing and stopped before counting sockets (cli#1233). The preview
now names the group and its recovery
(`codefly recover process-group PGID --preview`) and keeps listing; the
stop path names it the same way; clear's dry run prints what it could list.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Review on #1236: a regression test for clear's dry-run output. With one
group recorded by an older agent, the dry run logs the healthy group it
would stop, warns about the kept group with its recovery command, counts
the stale agent socket, returns the refusal, and signals nothing. It fails
with either half of the fix reverted.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@markwang-obin
markwang-obin added this pull request to the merge queue Oct 29, 2026
Merged via the queue into main with commit 1a987d1 Oct 29, 2026
20 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant