Handoff: Resume ContainerNursery protocol 0.0.427 verification after a compatible resolver is published

Written: 2026-07-30 04:24 UTC

RE-VERIFY: This is a write-time snapshot. Before acting, check the live resolver index, remote branch heads, and ContainerNursery origin/main. A newly published resolver or later upstream commit supersedes the version findings below. There is no upgrade pull request to re-check at write time.

Mission summary

The request was to confirm the existing ContainerNursery facade RPC loss on protocol 0.0.397, upgrade to protocol 0.0.427, find the lowest compatible published resolver, prove zero losses in at least four stress runs, and then open an unmerged pin-only ContainerNursery pull request from current main. The work stopped at the requested compatibility gate because no published resolver can start with protocol 0.0.427.

What was found and done

1. Read /code/ws/w8/FINDINGS.md, ContainerNursery AGENTS.md, and the full README. The prior evidence ties the lost response to protocol 0.0.397 submitting a large aggregate response write when a busy facade produces faster than the client link. Protocol 0.0.427 contains the 256 KiB request and response chunking commits 303c34ac and cea159ce.
2. Cloned ContainerNursery and checked out repro/facade-mid-rpc-stream-drop at b22ea019db6e5f10903afaca76296cd1cc20280b.
3. Ran the existing reproducer once on protocol 0.0.397 + resolver 0.0.653. It reproduced 86 lost responses out of 1,344 calls. There were 1,258 complete calls, no framed RPC errors, no incomplete calls, and no other failures. Every sampled lost call had already been answered by the backend.
4. Created and pushed verify/facade-fix-on-newer-protocol. Tested protocol 0.0.427 with resolver 0.0.653, 0.0.655, 0.0.670, and 0.0.680. Each clean build compiled, then failed during facade startup with AbstractMethodError: UrlProtocol2 does not implement GossipHandler.authenticatedInteractionSeverity(Object).
5. Checked every published resolver after 0.0.670 through the highest available 0.0.680. POMs target protocols 0.0.397, 0.0.399, or 0.0.409, and javap confirms their UrlProtocol2 classes lack the required method. Direct checks found no published resolver newer than 0.0.680.
6. UrlResolver main at https://github.com/CodexCoder21Organization/UrlResolver/commit/086927a2c8be309c61b2a5bff551e278ece6dec1 still pins protocol 0.0.409 and lacks the method, so its reserved future version 0.0.689 is not yet a usable candidate.
7. Applied the requested stop condition. A genuine protocol 0.0.427 stress run never reaches traffic, so there are no upgraded loss counts and no four-run zero-loss result. No clean pin-only branch, full ContainerNursery suite run, or upgrade pull request was created.
8. The Kompile build-result cache did not invalidate after the first dependency pin change and initially reused protocol 0.0.397. That result was rejected. Every reported compatibility attempt used a fresh cache and had its resolved JAR names checked. The cache problem was recorded at https://github.com/CodexCoder21Organization/PlanRepository/blob/main/challenges/2026-07-30-0405-kompile-build-result-cache-ignored-a-build-kts-dependency.md.

Relevant PRs / refs

| Item | Write-time state | |---|---| | Reproducer branch | Remote head b22ea019db6e5f10903afaca76296cd1cc20280b: https://github.com/CodexCoder21Organization/ContainerNursery/tree/repro/facade-mid-rpc-stream-drop | | Verification branch | Remote head faa35a6f7d8745c245e187200b4689143fdb9f1b; contains the sequential resolver trials and pickup-safe findings: https://github.com/CodexCoder21Organization/ContainerNursery/tree/verify/facade-fix-on-newer-protocol | | Remote verification findings | https://github.com/CodexCoder21Organization/ContainerNursery/blob/verify/facade-fix-on-newer-protocol/verification/facade-protocol-0427-findings.md | | Resolver-release blocker | url://handoff/handoffs/hf-2026-07-30-publish-a-urlresolver-release-compatible-with-protocol-0-0-427 |

No ContainerNursery pull request exists for this upgrade. Nothing was merged, deployed, or published.

The full 0.0.680 temporary build log was not pushed because almost all of it is dependency and compiler output; the exact causal stack and resolved JAR names are preserved in the remote findings. No credential-bearing or build-output artifact was committed.

Next steps

1. Re-verify current state first: check the resolver index, UrlResolver main, ContainerNursery main, and both linked branch heads.
2. Complete the linked resolver-release blocker. Confirm the published resolver POM targets protocol 0.0.427 and javap shows the required method on UrlProtocol2.
3. Return to the ContainerNursery reproducer branch and create a fresh verification branch if the existing one is stale. Pin protocol 0.0.427 and the lowest compatible resolver release.
4. Use a new Kompile result cache and confirm the build output names both intended JAR versions.
5. Run tests/stressTestUrlFacadeRpc_mixedTrafficNeverEndsAClientStreamWithoutAResponse.kts at least four times. Stop and report exact counts if any genuine upgraded run loses a response.
6. If all runs have zero losses, create fix/protocol-pin-chunked-writes from freshly fetched and rebased origin/main. Include only the two dependency pin changes, not the reproducer or verification findings.
7. Run the complete ContainerNursery suite with a fresh cache. Record any unrelated pre-existing failure, including the known possible testZombieCleanup_repeatedCrashRestartCycleDoesNotAccumulateOrphans flake.
8. Rebase immediately before opening the pull request, rerun tests if main changed, and open the unmerged pull request titled Chunk-safe protocol upgrade: bump foundation.url pins with the requested mechanism, evidence, deployment note, and Claude Code footer.
9. Monitor pull request CI to green. Do not merge or deploy without the user's explicit instruction.

Reusable / operational knowledge

• Baseline command: scripts/test.bash --test tests/stressTestUrlFacadeRpc_mixedTrafficNeverEndsAClientStreamWithoutAResponse.kts
• A changed build.kts dependency pin may reuse a stale Kompile build-rule result. Supply a fresh --cache-location and verify the JAR names printed in the compile classpath before accepting a run.
• The verification branch intentionally contains the reproducer history and failed dependency trials. It must not be used as the source of the final pin-only pull request.