Skip to content

Name the compaction fixture dir with the process id - #402

Merged
Blogbotana merged 1 commit into
Apibim-com:masterfrom
axisrow:bug/compaction-fixture-pid
Oct 25, 2026
Merged

Blogbotana merged 1 commit into
Apibim-com:masterfrom
axisrow:bug/compaction-fixture-pid

Conversation

@axisrow

@axisrow axisrow commented Oct 25, 2026

Copy link
Copy Markdown
Collaborator

Context

Under nextest's process-per-test model every test runs in its own process, so
crates/host/tests/compaction.rs Fixture::new can build identical temp dir
names in two processes started within one clock tick: the name is derived from
nanos plus a process-local counter. The second fixture then fails with
AlreadyExists. This is the same collision class as the recovery-test fix in
#335, but in the compaction fixtures; it surfaced as a macOS test-shard flake
on PRs where the diff itself was unrelated.

Fix

Include std::process::id() in the fixture directory name, so names are unique
per process even when nanos and the process-local counter coincide.

Acceptance

  • Several consecutive nextest runs of the compaction suite pass with no
    AlreadyExists collisions (verified on macOS: 3 consecutive runs, 18/18 each).
  • No behavior change outside the fixture directory name.

Related

The fixture names its temp directory test-{nanos}-{counter}, but the
counter is process-local: under nextest's process-per-test model every
test starts in a fresh process with the counter at 0, so two test
processes starting within the same nanosecond build the same name and
one fails with AlreadyExists. This made the compaction suite flaky in a
way that only restarting the job fixed. Adding the process id to the
name makes concurrent test processes unable to collide.
@axisrow
axisrow requested a review from Blogbotana as a code owner October 25, 2026 14:13
@Blogbotana
Blogbotana merged commit cedf57f into Apibim-com:master Oct 25, 2026
34 checks passed
Blogbotana added a commit that referenced this pull request Nov 1, 2026
The platform no longer knows steel. The steel half of layer-engine (the
hooks behind Shape::Discipline and Change::Discipline, the steel readers,
writers and definitions, the read-back discipline, the authoring facade and
its tests) moves into steel::layer, and the Cargo edge flips: steel depends
on beamcraft-layer-engine, no platform crate depends on steel, and steel is
kind `discipline` in the F08 table. The registry starts empty; both apps call
steel::layer::install() at start (the window reads layers through session).

The remaining branching on the kind goes too. steel::engine::part::PartRecord
chooses between the per-kind pairs (copy, P11 copy, array, patch with
re-evaluation, quantity record), so the CLI copy, array and update-element
adapters drop CopiedElement, UpdatedElement and Target. The engine's queries
ask ElementKind::is_part and is_linear_member instead of matching Plate,
Beam or Column.

Stored bytes, refusal codes and command output are unchanged. Left on
purpose, with reasons in docs/design/element-interface.md section 8: no
platform trait and no ElementPatch split (the UpdateElement/v2 fingerprint),
one SCHEMA_DESCRIPTOR, and the /World/Steel prim paths and F06 tokens, which
are format, not behaviour.

The layer-engine move and the flip are axisrow's series from their fork
(axisrow/BeamCraft #394, #398-#402, #404, #407, #411, #412), ported onto
master.
Blogbotana added a commit that referenced this pull request Nov 1, 2026
The platform no longer knows steel. The steel half of layer-engine (the
hooks behind Shape::Discipline and Change::Discipline, the steel readers,
writers and definitions, the read-back discipline, the authoring facade and
its tests) moves into steel::layer, and the Cargo edge flips: steel depends
on beamcraft-layer-engine, no platform crate depends on steel, and steel is
kind `discipline` in the F08 table. The registry starts empty; both apps call
steel::layer::install() at start (the window reads layers through session).

The remaining branching on the kind goes too. steel::engine::part::PartRecord
chooses between the per-kind pairs (copy, P11 copy, array, patch with
re-evaluation, quantity record), so the CLI copy, array and update-element
adapters drop CopiedElement, UpdatedElement and Target. The engine's queries
ask ElementKind::is_part and is_linear_member instead of matching Plate,
Beam or Column.

Stored bytes, refusal codes and command output are unchanged. Left on
purpose, with reasons in docs/design/element-interface.md section 8: no
platform trait and no ElementPatch split (the UpdateElement/v2 fingerprint),
one SCHEMA_DESCRIPTOR, and the /World/Steel prim paths and F06 tokens, which
are format, not behaviour.

The layer-engine move and the flip are axisrow's series from their fork
(axisrow/BeamCraft #394, #398-#402, #404, #407, #411, #412), ported onto
master.
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.

2 participants