← ArchiveArea
Completed

Finish required CI for reviewed startup shutdown ownership

A11 fix is pushed and locally verified at 4b064886; required run d657047e is pending amid shared allocation failures.

Handoff document

Markdown

Obtain required CI and supervisor review for startup shutdown ownership

Snapshot: 2026-09-27 18:13 UTC. CN14 outcome is REQUEUED-INFRA under the shared allocation health rule; claim is being released.

Remaining work

  1. Required kotlin.build (remote) attached normally at https://buildtest.kotlin.build/run?id=d657047e and was PROVISIONING at 18:12 UTC. The PR remains OPEN at 4b064886743daca6c251ca3067d3b467c4b667f2. Shared allocation failures meet the sweep policy requeue rule; assess the existing run and infrastructure before supervisor final review. No identical-tree commit or rerequest occurred.
  2. Once required CI is green, the supervisor must perform final review and merge. CN14 must never enqueue, merge, rerequest or deploy. The ownership finding itself is corrected and locally validated.
  3. Continue sibling prerequisite work only in its own lane after the startup PR lands. CN14 has not changed https://github.com/CodexCoder21Organization/ContainerNursery/pull/629 or https://github.com/CodexCoder21Organization/ContainerNursery/pull/609. Historical prerequisites https://github.com/CodexCoder21Organization/ContainerNursery/pull/630 and https://github.com/CodexCoder21Organization/ContainerNursery/pull/627 were already merged.

Remote state

  • Existing PR branch wip/adoption-hook-startup-W44: https://github.com/CodexCoder21Organization/ContainerNursery/pull/635 at 4b064886743daca6c251ca3067d3b467c4b667f2. Verified OPEN at exact expected d058a3f5 immediately before the force-with-lease push under the repository lock; ls-remote confirms the new head. Main remained d3acb54e through the final fetch/rebase. PR body now contains Shutdown ownership, complete local evidence, original WHY opening and required footer.
  • Fixed side checkpoint: https://github.com/CodexCoder21Organization/ContainerNursery/tree/wip/cn14-635-adoption-lock-2026-09-27 at the same reviewed head.
  • Test-only fail-first commit remains in history: https://github.com/CodexCoder21Organization/ContainerNursery/commit/0eea6e5009c647aa29e5dbf83947bf2a0d34184f.
  • No deployment or Maven publication. All CN14 code is committed and pushed. No generated artifacts are committed.

Mechanism and ruling A11

The old monitor covered the full adoption pass, including probes, canary creation and state writes. The shutdown hook needed it, so a held adoption step prevented restart cleanup inside the watchdog's unchanged 10-second grace. Adoption and cleanup now run outside that monitor. Restart shutdown interrupts adoption before waiting for its current ownership transition, then releases acquired children; unvisited children retain their previous release. Acquired handles are published before interruptible metadata callbacks. Completion latches keep one cleanup owner through completion, including rollback. Final shutdown completes adoption and stops every child.

Independent review found an initial unconditional-cancellation version would leave unvisited children running on final shutdown. A fail-first control proved that issue, and interruption is now scoped to restart handoff. The reviewer approved the final full diff and test design with no remaining blocking finding. OS operations that are individually non-interruptible are source-reviewed, not claimed as a tested cancellation guarantee.

Completed evidence

  • New held two-child watchdog subprocess: failed 2/2 on original d058a3f5 at the unchanged ten-second assertion, total times 15.676s and 15.738s. Final source passes 20/20 in separate Gradle invocations.
  • CN13 SIGTERM-during-adoption case: final source passes 20/20. Its obsolete assertion that SIGTERM must wait was explicitly changed under A11 to require completion within the same bound; child preservation, next restart, PID and argv assertions remain.
  • Public Clock interruption after canary creation: failed 1/1 against the original adoption implementation; passes with acquired-handle publication.
  • Ordinary final shutdown with two children: failed 1/1 against unconditional cancellation; passes with restart-only cancellation.
  • Seven named Gradle neighbours: 24/24, all 21 inherited cases plus three new cases, no failures/errors/skips.
  • One full local kompile suite at exact pushed head: 622/622 plus two successful build rules, 622 unique test names and one successful record each, no failed or duplicate attempts. Acquired shared suite slot 17:58:09 UTC and completed 18:07:01 UTC. No full suite rerun is needed without a new tree.

Evidence files and resume notes

CN14/out/findings.md records the incremental plan and facts. CN14/out/merge-candidate-635.md contains the review/validation record; its verdict remains pending required CI. Individual baseline and repeated XML files, full-local-final.xml, full-suite-summary.txt and review-ownership.md retain evidence and complete failure stack traces. Checkout is CN14/ws/ContainerNursery, clean at the pushed head. Existing W44 history: https://github.com/CodexCoder21Organization/ContainerNursery/tree/wip/handoff-evidence-W44/handoff-evidence/W44.

RESUME

  1. Fetch current state of https://github.com/CodexCoder21Organization/ContainerNursery/pull/635 and confirm head 4b064886743daca6c251ca3067d3b467c4b667f2. Check claims before taking ownership. All code is pushed to the PR and side checkpoint; no local-only change remains.
  2. Watch the existing required run https://buildtest.kotlin.build/run?id=d657047e using build-watchman --run d657047e (read-only). It was PROVISIONING at 18:12 UTC. GitHub required check was in_progress at 18:13 UTC. Never rerequest, enqueue, merge or deploy from this lane. No identical-tree commit was needed because the check attached normally.
  3. Observe the shared allocation incident: https://buildtest.kotlin.build/run?id=e449f129 and https://buildtest.kotlin.build/run?id=b28264c0 both failed with DropletServiceCallStalledException: listDroplets stalled for 30000ms; https://buildtest.kotlin.build/run?id=3880dde5 failed allocation on a listDroplets transport error. All were scheduled around 17:58 UTC. Sweep policy's two-recent-infrastructure-failures rule requires REQUEUED-INFRA. Do not treat these other runs as a test failure on this PR.
  4. Once required checks are green and infrastructure policy permits proceeding, supervisor final review is the remaining gate. Local suite need not be repeated without a changed tree: exact pushed head passed 622/622 plus two build rules, 24/24 Gradle neighbours, and both required signal scenarios 20/20. The independent full-diff review has no remaining blocking finding.

Shared infrastructure evidence

Recent buildtest allocation failures stop the CN14 CI watch under sweep policy

While confirming required CI for https://github.com/CodexCoder21Organization/ContainerNursery/pull/635 at 4b064886743daca6c251ca3067d3b467c4b667f2, the buildtest list showed three allocation failures scheduled around 17:58 UTC on 2026-09-27. All are newer than the policy health cutoff. The policy states that two or more recent infrastructure failures require checkpointing and REQUEUED-INFRA without retrying. The PR's own required run https://buildtest.kotlin.build/run?id=d657047e was PROVISIONING during the read-only watcher assessment; this is not an observed code failure or evidence that this particular run has failed.

Run https://buildtest.kotlin.build/run?id=e449f129 (BuildTestRunner), scheduledAt=1790531937946, completedAt=1790532080645:

Could not verify droplet cleanup before requeueing runId=e449f129 during allocation failure: DropletServiceCallStalledException: Droplet service call listDroplets stalled for 30000ms during findDropletsByNamePrefix.. The run was failed without re-entering admission.

Run https://buildtest.kotlin.build/run?id=b28264c0 (CodexCoder21Organization/TemplateCli), scheduledAt=1790531929987, completedAt=1790532080639:

Could not verify droplet cleanup before requeueing runId=b28264c0 during allocation failure: DropletServiceCallStalledException: Droplet service call listDroplets stalled for 30000ms during findDropletsByNamePrefix.. The run was failed without re-entering admission.

Run https://buildtest.kotlin.build/run?id=3880dde5 (lane-FBTE2), scheduledAt=1790531902218, completedAt=1790532050634:

Could not verify droplet cleanup before requeueing runId=3880dde5 during allocation failure: RuntimeException: Sandboxed code threw an exception: java.lang.InternalError: Exception encountered in implementation of foundation/url/sjvm/intrinsics/ServiceBridge:rpc(Ljava/lang/String;Ljava/util/Map;)Ljava/util/Map; : foundation.url.resolver.PersistentRpcConnection$AmbiguousRpcRequestException: RPC request 'listDroplets' to service 'digitalocean-droplets' has an ambiguous outcome because its transport failed after the request write began. The request was not replayed because the remote handler may already have run. Original transport failure: Persistent RPC connection to service 'digitalocean-droplets' was closed while requests were still pending. Reader transport failure: java.io.EOFException: Stream closed while reading message data (read 0 of 4 bytes). cause: foundation.url.resolver.UrlResolutionException: Persistent RPC connection to service 'digitalocean-droplets' was closed while requests were still pending. Reader transport failure: java.io.EOFException: Stream closed while reading message data (read 0 of 4 bytes).. The run was failed without re-entering admission.

Impact: local work and PR push are complete, but the lane cannot declare a green required-check merge candidate. No workaround or retry was applied; leave the existing required run intact. Suggested owner action: inspect allocation/listDroplets transport and cleanup confirmation, then assess the existing run. The report-challenge CLI was not invoked because it automatically enqueues and merges, which this lane expressly forbids. This evidence is retained in the handoff and lane files.

No status reports yet.

Completed Sep 27, 2026 · 19:11 UTC This handoff is read-only in ArchiveArea.