Summary
test_contract_operations_via_docker_nat failed once in CI (TRY 1) then passed on retry (TRY 2), in the NAT Validation job.
Verbatim failure
thread 'test_contract_operations_via_docker_nat' (27155) panicked at apps/freenet-ping/app/tests/docker_nat_test.rs:57:10:
Failed to build Docker NAT network: ConnectivityFailed("Network did not reach 100% connectivity within 120s")
nextest summary: 2 tests run: 2 passed (1 flaky), 16 skipped / FLAKY 2/3
Not a duplicate of #5175 / #4910
Those two issues concern test_nat_subscription_cross_peer_update_via_docker_nat, a different test in the same family, with a different, already-diagnosed root cause (a fixed 10s propagation sleep). This failure is distinct: it occurs during Docker NAT network bring-up (the .build() connectivity-establishment phase, .connectivity_timeout(Duration::from_secs(120))), before the test body itself runs. Please don't dedupe/close against those.
Hypothesis (unconfirmed)
Possible resource exhaustion / timing sensitivity under CI load: this network is 1 gateway + 3 peers, and the 120s connectivity deadline may occasionally be exceeded when the shared CI runner is under load (contended CPU/network for Docker's own networking setup). This is a hypothesis only — confirming it would require correlating this failure with concurrent runner load and Docker daemon bring-up timing at the time of the run, which hasn't been done.
Per repo policy, raising the hard deadline is not the preferred fix without understanding root cause — a bring-up mechanism that polls/backs off rather than assuming a fixed wall-clock budget might be more robust, but that's an option to evaluate, not a prescribed fix.
Ask
Investigate root cause of the occasional bring-up connectivity failure in Docker NAT test setup. Do not simply raise the timeout without understanding why 120s is occasionally insufficient.
[AI-assisted - Claude]
Summary
test_contract_operations_via_docker_natfailed once in CI (TRY 1) then passed on retry (TRY 2), in the NAT Validation job.apps/freenet-ping/app/tests/docker_nat_test.rs:57— the.build().await.expect("Failed to build Docker NAT network")call, inside the test fn starting at line 33.pull_requestfor PR feat(obs): measure the notification leg's summary agreement rate (R4b instrument) #5294 (branchobs/r4b-single-entry-agreement-rate), headShab7c55730a60b061930292e41ac3b0618b11a57d1Verbatim failure
nextest summary:
2 tests run: 2 passed (1 flaky), 16 skipped/FLAKY 2/3Not a duplicate of #5175 / #4910
Those two issues concern
test_nat_subscription_cross_peer_update_via_docker_nat, a different test in the same family, with a different, already-diagnosed root cause (a fixed 10s propagation sleep). This failure is distinct: it occurs during Docker NAT network bring-up (the.build()connectivity-establishment phase,.connectivity_timeout(Duration::from_secs(120))), before the test body itself runs. Please don't dedupe/close against those.Hypothesis (unconfirmed)
Possible resource exhaustion / timing sensitivity under CI load: this network is 1 gateway + 3 peers, and the 120s connectivity deadline may occasionally be exceeded when the shared CI runner is under load (contended CPU/network for Docker's own networking setup). This is a hypothesis only — confirming it would require correlating this failure with concurrent runner load and Docker daemon bring-up timing at the time of the run, which hasn't been done.
Per repo policy, raising the hard deadline is not the preferred fix without understanding root cause — a bring-up mechanism that polls/backs off rather than assuming a fixed wall-clock budget might be more robust, but that's an option to evaluate, not a prescribed fix.
Ask
Investigate root cause of the occasional bring-up connectivity failure in Docker NAT test setup. Do not simply raise the timeout without understanding why 120s is occasionally insufficient.
[AI-assisted - Claude]