sandbox: a setup assertion walked a tree that still held the warm-up worker #208

Merged

dcharlot merged 2 commits from dcharlot/tree-energy-setup-race into main 2026-10-10 17:16:42 -04:00 AGit

Conversation 0 Commits 2 Files changed 4 +36 -4

2026-10-10

David Charlot

lockfiles: three workspaces' locks did not list a dependency jcp-efficiency grew ...

`jcp-efficiency` gained a `serde` dependency. Its own workspace's lock
(`jcp/jcp-rs`) records it; the three other workspaces that reach that crate
through a cross-workspace path dependency do not, so on current main:

  cargo metadata --locked   in sandbox-rs, jouledesk-rs, joulehook-rs   FAILS

Measured both ways — those three fail `--locked` at 8f62e388 and pass with
this commit. Nothing else moved: one `"serde",` line per lock, resolved by
cargo itself rather than written by hand.

Nothing caught it because no workflow passes `--locked`, so CI silently
re-resolves and goes green while the committed lock is wrong. The visible
symptom is instead that building any of those three workspaces leaves a dirty
`Cargo.lock` behind, which is how this surfaced: a `cargo test` in sandbox-rs
dirtied the tree while I was verifying the commit before this one.

This is the shape the repo keeps producing — a shared crate's manifest changes
and only its own workspace's lock is refreshed. There are ~25 workspaces and
no single build that covers them, so the rule has to be: after changing a
crate's dependencies, refresh every lock that names it
(`grep -rl 'name = "<crate>"' --include=Cargo.lock`), not just the one
beside it.

Co-Authored-By: Claude Opus 5 <[email protected]>

b1d7e1e2b2

• View at this point in history

2026-10-10 10:01:38 -04:00

David Charlot

sandbox: a setup assertion walked a tree that still held the warm-up worker ...

`a_worker_reaped_while_its_tree_is_walked_is_never_missed` fails about one run
in five on the dev Mac, always the same way:

  assertion `left == right` failed: setup: the server and its 60 idle children
    left: 62
   right: 61

Not load, and not the behaviour under test — the setup. The perl server's
worker is

  if ($p == 0) { print "$$\n"; my $x = 0; $x += $_ for 1 .. 150000; exit 0 }

so it prints its pid *before* doing its work. `ask("warm up")` returns as soon
as that line is read, which is while the worker is still running, still the
server's child, and not yet reaped. The next line walks the tree and finds 62
members. The comment above it said "the tree is quiet before the first span",
and that is the part that was not true; load only widens the window.

So the setup waits for the shape it asserts instead of asserting it on the
first walk, through a `settled_tree(root, want)` in the same idiom as this
file's `quiet()` — poll, return when it matches, panic after 20 s naming the
tree it last saw. The test's own assertions are untouched, and the guard still
fails the test if the tree never settles, so nothing here is weakened: a walk
that cannot find the shape still stops the run.

Measured on this host: 2 failures in 5 runs before, 12 passes in 12 after.

The file's three other tree-count assertions were checked and are sound —
their workers are long-lived (the awk blocks on `getline`), or the walk
happens before any request, so there is no transient child to catch.

Found while replicating `macos-energy-backend` locally for #183; it is the
only failure in that job and it is unrelated to that PR, which touches
`mesh/` alone.

Co-Authored-By: Claude Opus 5 <[email protected]>

52fe6bff6f

• View at this point in history

2026-10-10 09:58:26 -04:00