← Priority list

Merge campaign steps 3–5 stopped on ContainerNursery queue failures

ContainerNursery queue causes are reproduced and corrected on pull request 492; fresh checks are pending before the ordered merge campaign resumes.

hf-2026-07-31-merge-campaign-steps-3-5-stopped-on-containernursery-queue-failures

Edit handoff

Add dependency

Complete this handoff

Moves it out of every priority list and into ArchiveArea.

Handoff document

Markdown

Merge campaign steps 3–5

Updated: 2026-07-31

Mission

Land these pull requests in order through their normal merge queues, with at most one organization-wide queue entry active:

  1. https://github.com/CodexCoder21Organization/ContainerNursery/pull/492
  2. https://github.com/CodexCoder21Organization/ContainerNursery/pull/559
  3. https://github.com/CodexCoder21Organization/kotlin-build-ci/pull/199

Use build-watchman through terminal completion. Do not bypass checks, loosen tests, or merge out of order.

Current state

https://github.com/CodexCoder21Organization/ContainerNursery/pull/492 remains open. Its branch has been updated normally, without force, to 82679c67bd8b0c9a632f3e32a2e7ceda3986f768. Fresh branch checks are pending. No pull request has been re-enqueued yet, and steps 4–5 remain untouched.

Queue failure disposition

The failed GitHub Actions task was :test, specifically RollingFileLogCaptureTest.reopeningStoreAfterRotationReadsArchivesAndPrimary. The full stack entered okio.fakefilesystem.FakeFileSystem.findOpenFile from RollingFileLogCapture.snapshotSource while constructor timestamp recovery and getLines() used the same fake filesystem concurrently. The runner stayed alive and Gradle produced an ordinary 810-test summary, so this was a test-harness defect, not Gradle, a build script, or runner loss.

A 64-caller public-path amplifier against the old fake filesystem failed 10/10, including the exact ConcurrentModificationException. The corrected test uses an isolated real filesystem path and keeps the 64 concurrent reopen/read callers; it passed 10/10.

The previous remote run's three failures shared lease L0 on one constrained worker. The 100 MB upload test was CPU-bound in random-data compression and 8 KB TLS writes while both real child-JVM tests failed before normal server startup logs appeared. Existing one-CPU evidence for the upload fixture was 10/20 failures before and 20/20 passes after switching the same 100 MB entry to STORED form. The exact three-test set passed 3/3 together under taskset -c 0 after the correction.

Pushed commits:

  • 3c3cd0eea988e5fecd411b2725839e7c2627a796 — Use concurrent filesystem in recovery test
  • f012830e3021c1bf6cfeba423969a97034aaedd5 — Stress concurrent log recovery reads
  • 82679c67bd8b0c9a632f3e32a2e7ceda3986f768 — Make large upload test fixture efficient

The full Gradle suite passed after rebasing on current main in 10m21s. Independent test and diff reviews found no weakened assertion, payload, timeout, memory limit, or public behavior. Generated build files were removed before push.

Next actions

  1. Use build-watchman 0.0.13 on https://github.com/CodexCoder21Organization/ContainerNursery/pull/492 through fresh head checks and merge-queue completion. Verify no other organization-wide queue entry before enqueue.
  2. After it merges, perform the required focused adversarial review of https://github.com/CodexCoder21Organization/ContainerNursery/pull/559, then use build-watchman through merge if the review is clean.
  3. After that merges, require fresh green checks and perform the focused review for https://github.com/CodexCoder21Organization/kotlin-build-ci/pull/199 before its queue entry.
  4. Complete this handoff only after all three pull requests are merged.

Detailed live findings: /tmp/claude-1000/-code/6c96afa8-6573-484c-a7c0-84b84bafb359/scratchpad/out/m1d-findings.md