Establish a consistent trigger for the ContainerNursery first-attempt function limit

Original request

Lane F5b was asked to reproduce the first-attempt timeout of ContainerNursery testJarHistoryBoundsDeployments under the conditions CI actually used, then make a root-cause fix only after a reliable public-path reproducer. The cited CI is https://github.com/CodexCoder21Organization/ContainerNursery/actions/runs/39694112529 .

The broader provenance remains: The owner reported that https://droplets.wasmserver.com/ "is super unreliable, frequently rendering various errors/notices due to bugs in UrlResolver or UrlProtocol or something else" and asked for the underlying root cause to be fixed; the ContainerNursery route stops the WUI after 5 idle minutes, so most human visits are cold starts.

State verified in F5b

• Original CI revision: https://github.com/CodexCoder21Organization/ContainerNursery/commit/081368ee33808fc0e427da3c9fe6c6d293dc351a . First target attempt: 33598 ms at a 30000 ms function budget; next attempt: success in 22395 ms. Two distinct caller samples, each repeated in output, show JAR generation and hash formatting near generated test lines 251/253.
• The XML has durations and first-completion ordering, with no absolute test start/end timestamps. The Actions log has no target test name. Exact original companions cannot be recovered from those saved records.
• Complete local replay on main 45324dc2b27b1d1562887b9023e463ecafc0e32e: target success on attempt one, 7604 ms; 854/855 final records succeeded, with one dependency-download preparation result.
• Complete local replay on the original CI revision: target success on attempt one, 18272 ms; 850/850 final records succeeded. Another scenario had two attempts; the target had one.
• A 166902 ms CI case, stressTestServerSurvivesMidNegotiationChurnDropWithConstrainedHeap, is near the target in CI completion order. It runs ten real clients opening child streams for 150000 ms. Both local suite directory orders ran it well before the target rather than alongside it.

Co-scheduled evidence, verify rather than repeat

The evidence-only runner selects 39 real CI cases from completion records 260 through 311, keeping the long companion in an initial slot. It uses LocalBuildWorkspace.prepareTestBatch, width four, and maxTestAttempts=1. Other selected cases are admitted once all ten existing cn-churndrop client workers are visible in the companion process. Test source and JVM options are unchanged. These are CI-neighborhood cases, not a proven exact original schedule.

The rate is 1/4, below the required 50 percent. All four companion cases passed, with durations near 166 seconds; the other selected cases also passed. co-ci-1 has its caller WAITING in NettyApplicationEngine.stop through HttpFacadeProvider.shutdown at generated target line 300. CI's caller was RUNNABLE in hash calculation. This difference remains unresolved.

Phase timing

A separate diagnostic source copy passed on its first attempt: XML 27266 ms, internal phase markers 22943 ms through cleanup. The 200-iteration section consumed 18135 ms; expected-hash generation consumed 52 ms; HTTP stops consumed 1054 and 2141 ms. All 35 assertions and repeat(200) remain intact. Removing the markers and restoring the entry name reproduces the original source byte-for-byte. The temporary source was removed afterward. This run is separate from the unchanged four-run rate.

The iteration section combines HTTP transfer, activation and persistence waits. Its cost dominates this profile, but those costs are not yet separated, and a common mechanism with the CI sample is unproved. The public console entry API has no capture timestamp; the phase copy supplies its own Clock-based timestamps.

Durable work

• Evidence branch: https://github.com/CodexCoder21Organization/ContainerNursery/tree/wip/laneF5b-evidence/laneF5b .
• Latest checkpoint: https://github.com/CodexCoder21Organization/ContainerNursery/commit/6ef1cd0bbd4ab5342f26b9f27ee32fd86f02eea7
• First co-scheduled function-limit checkpoint: https://github.com/CodexCoder21Organization/ContainerNursery/commit/5708cdc670f3fdfcc74597c6b705b2905acc9149 .
• Findings: https://github.com/CodexCoder21Organization/ContainerNursery/blob/wip/laneF5b-evidence/laneF5b/rF5b-findings.md .
• Final report: https://github.com/CodexCoder21Organization/ContainerNursery/blob/wip/laneF5b-evidence/laneF5b/rF5b-final.md .
• Prior F5 evidence: https://github.com/CodexCoder21Organization/ContainerNursery/tree/wip/laneF5-evidence/laneF5 . Its 10 solo and 80 independent-child attempts passed.

The branch holds original CI XML and Actions logs, extracted attempt output, two suite replay XML files and schedules, all four co-scheduled XML files and lifecycle events, the profile source and manifest, phase timings, and reproducible runner sources. Read each target's XML outcome; helper exit zero records batch completion.

Concrete next work

1. Recover the laneF5b helper files into a new lane root and clone fresh repositories under its workspace directory. The diagnostic baseline is pinned to the original CI revision intentionally. Read each repository README and AGENTS before execution.
2. Use the saved phase copy and F5 transport probe to separate HTTP transfer, activation and persistence time within the 200-iteration section under the real companion workload. Identify an exact observable condition before a code change.
3. Obtain scheduler event timing from a future CI run if the exact original companion schedule is needed. Duration-only XML cannot supply it.
4. Reach a consistently red public-path test before a root fix. Then complete ten successful first attempts, a reversal control, correctness reviews and the PR checks required by the brief. No PR exists for F5b.

To recover the candidate, copy the evidence helper sources to the new lane root, prepare workspace/ContainerNursery-ci and its normal launcher, then run compile_co_probe.py and run_co_probe.py with a fresh output prefix. For the separate timing copy, use build_profile.py, validate_profile.py, compile_co_probe.py --profile, and run_profile_probe.py. Use the saved co-profile-specs.txt for the diagnostic case. The profile runner preserves the workload and removes its temporary source afterward.

Constraints and limits

No product source or existing test was changed. No fix, reversal control, PR, merge, production deployment or artifact publication was performed. No budget increase, iteration reduction, assertion change or new JVM option was used. Keep all lane data off product PR branches. Continue local testing only, use the shared suite-slot.sh for complete suites, retain attempt history, and poll GitHub no faster than every two minutes. Keep ordinary engineering wording and parse raw diagnostic files without printing them.

This host is aarch64 with 16 logical processors and a 10 GiB memory limit; CI records reference amd64. Width four does not establish identical platform timing. No processor restriction or artificial load was added.

Required reading: https://github.com/CodexCoder21Organization/DocumentationRepository/blob/main/architecture/TESTING.md and https://github.com/CodexCoder21Organization/DocumentationRepository/blob/main/PHILOSOPHY.md . Runner behavior was checked at https://github.com/CodexCoder21Organization/kompile-core/commit/40680b32ed8dce4841ee801479da3230e0632d8c .