Investigate Windows parallel runner validation failures without weakening safety checks

[shyamsridhar123]

Outcome

Make the standard Windows runner validation reliable under parallel test execution without weakening production teardown/checkpoint safety or hiding failing assertions. Keep this separate from #211's native stopped-session evidence-access prerequisite.

Observed September 9, 2026

At base 8198c4a plus the cfg(test)-only #211 diagnostic patch, cargo test --offline --locked --workspace --target-dir target reached the runner suite and returned 188 passed / 7 failed / 1 ignored, in 166.33s. The 11 new #211 pure/wire tests pass. The seven failing test bodies and production lifecycle implementation are unchanged; main.rs only gains cfg(test) module registration. No baseline parallel control was run, so regression origin is not established.

Failures:

• adapter::external::tests::claude_permission_bridge_denies_rejection_and_expiry: approval-request timeout.
• source_checkpoint::tests::issue190_cancelled_exit_checkpoints_before_terminal_event: 0 checkpoint proofs instead of 1.
• source_checkpoint::tests::issue190_cleanup_commit_rejects_a_late_retention_acknowledgment: elapsed timeout.
• source_checkpoint::tests::issue190_late_stop_cancels_held_ack_without_acceptance_or_post_verifier_seal: elapsed timeout.
• source_checkpoint::tests::issue190_stop_wins_over_provider_completion_and_seals_source: 0 checkpoint proofs instead of 1.
• source_checkpoint::tests::issue190_suspend_wins_over_provider_completion_and_seals_source: 0 checkpoint proofs instead of 1.
• tests::teardown_fail_closed_execute_assignment_preserves_exact_workspace_until_verified: teardown uncertainty observation timed out.

Full output is retained in the owning QA evidence directory, issue211-rust-final-20260909T191835097/workspace-tests.log. The established #210 gate explicitly used RUST_TEST_THREADS=1 and --test-threads=1; that same serial workspace lane has now completed without changing these tests or timeout values: 458 passed / 0 failed / 276 ignored overall, including 195 passed / 0 failed / 1 ignored in the runner (810.90s). The complete serial result is retained at issue211-serial-workspace-20260909T192525276/workspace-tests.log. This is not a green parallel-suite claim and does not establish causality.

Acceptance

• Compare a bounded baseline/current run and identify fixture scheduling/resource contention versus an actual product lifecycle defect; do not guess causality from a retry.
• Keep exact source/policy/checkpoint/termination assertions and fail-closed behavior.
• Prefer owned, observed readiness/completion signals and bounded process resources over guessed sleeps or blanket timeout increases.
• Retain the original failure and exact local reproduction/outcomes; hosted Actions availability is not the gate.
• If serialization is the supported local contract, document and enforce it consistently in contributor commands while tracking any remaining parallel limitation explicitly.
• No real inference, production/app-DB mutation, or teardown of shared/manual services for a test-fixture investigation without its separate owned authorization.

This issue is curated follow-up work, not factory-ready and not a claim that a runtime defect is proven.

[shyamsridhar123]

Additional serial failure evidence - September 9, 2026

The #211 retained-receipt implementation's full serial workspace gate is not green. With RUST_TEST_THREADS=1 and --test-threads=1, the runner portion returned 205 passed / 2 failed / 1 ignored, 2146.90s. The gate stopped before the server/store unit binaries ran.

• source_checkpoint::tests::issue190_cancelled_exit_checkpoints_before_terminal_event: zero checkpoint proofs, expected one (source_checkpoint.rs:419).
• source_checkpoint::tests::issue190_unpinned_legacy_source_retains_without_checkpoint_proof: existing ten-second readiness wait elapsed (line402).

Each was then run exactly, serially, on the same compiled runner binary, without source, assertion or timeout changes, using the same serial test flag: cancelled case PASS in14.73s; unpinned case PASS in13.86s. Those isolated passes neither establish causality nor turn the full failure into a pass. The native capture deadline remains10s and test execution bound20s; neither was raised.

The relevant existing test bodies and production checkpoint module are unchanged from cf357fc; its fixture only supplies None for the two newly added Assignment fields. The new #211 provider-free collection path has 12 passing Windows runner cases, 16 domain/server cases and15 actual-store cases. One additional receipt test is Unix-only. No claim of global deadlock freedom, a green parallel suite, or complete release validation is made.

Retained local receipts: 20260909T223127531-issue211-retained-workspace-serial, 20260909T231329393-same-binary-issue190_cancelled_exit_checkpoints_before_terminal_event, and 20260909T231346950-same-binary-issue190_unpinned_legacy_source_retains_without_checkpoint_proof. The same-binary receipts include its SHA256. A controlled baseline/current comparison and bounded failure-event diagnostics remain needed. During the full run, parent performed read-only app/browser inspection and existing same-role QA expiry maintenance; no test-relevant causal claim is inferred from that overlap.

No real inference, shared-service teardown, app-source edit, counter reset, or weakening of checks was used for this investigation.

[shyamsridhar123]

Bounded diagnostic result - September 9, 2026 (local)

The matched shared slice did not reproduce the failures:

• Baseline cf357fc + passive diagnostics:17/17 passed,109.33s.
• Current d9581c1 + identical diagnostics:17/17 passed,131.56s.
• Two invocations total; no reverse-order or repeat-until-green runs.

The previously failing cancelled case reached readiness in779/1035ms and captured its checkpoint in2405/2584ms. The unpinned control reached readiness in1029/1728ms and correctly retained source without minting proof. Existing10s/20s bounds, assertions and control ordering were unchanged.

A separate, single full current runner trace then passed 207 tests /0 failed /1 intentionally ignored,1141.68s. It did not reproduce either earlier failure. This remains inconclusive about cause, not a claim of reliable parallel execution, a fixed product defect, or a full-workspace release pass. Earlier failures remain retained.

Build-provenance safeguard: before any paired test ran, validation detected Cargo reusing baseline bytes for current in the shared experimental target. The invalid current receipt/copy was retained and rejected. Native package-only cleaning of all three local crates, explicit manifest/source checks, fresh-artifact verification, different executable hashes and baseline0/current12 feature-test markers established the actual pair. No global cache/source/app deletion or credential operation was used.

Canonical PR215 remains clean/draft at d9581c1. A source-bound canonical workspace validation is now underway; diagnostic-copy success will not be substituted for its gate. No native application upgrade or provider/history call has occurred.

[shyamsridhar123]

Additional retained Windows observation, September12: PR234 at unchanged native Rust source/head bb3a38f had two setup timeouts in connections::integration_tests::{native_fixture_personal_github_profiles_and_login_replay_survive_restart,native_fixture_ready_ack_refresh_rejection_and_old_run_pins_survive_restart}. Run34678831576, first Windows job103513485892: 188 passed /2 failed at integration_tests.rs143 while opening the native manager.

Exactly one targeted Windows-only rerun on the same head passed. No source, assertion, timeout, thread-count or safety changes were made. The full native integration and the other jobs pass. This is an intermittent setup-timeout observation, not proof of a diagnosed global cause or closure of #213. The failed job/log remains retained.

[afateen]

Supplementary Windows fixture evidence from #79 / PR #307

The two connection fixtures in the September 12 observation also appeared in our #79 validation. Adding the environment classification here rather than opening a duplicate issue.

This is retained evidence from the #79 candidate, not a fresh reproduction on current main, not proof of the same cause as the earlier setup timeouts, and not acceptance evidence for closing #213.

• The earlier full-workspace run, before the final CLI selector correction, returned 517 passed / 36 failed / 329 ignored.
• A bounded serial rerun of the 33 non-privilege-dependent runner failures used the actual runner test executable with a new, short, owned TEMP/TMP outside source checkouts: 31 passed / 2 failed / 0 ignored / 181 filtered out.
• The 24 cases previously reporting path-length failures and seven other assertion failures passed in that diagnostic rerun. Changing the layout and execution conditions does not establish which factor caused the original failures or turn the full gate green.
• These two cases still failed, now reporting private connection directory permissions could not be established:
  • connections::integration_tests::native_fixture_personal_github_profiles_and_login_replay_survive_restart
  • connections::integration_tests::native_fixture_ready_ack_refresh_rejection_and_old_run_pins_survive_restart
• Three earlier Windows symlink-privilege cases were not rerun. Those three plus the two connection cases remain unverified on this host.

Environment: Windows, Rust 1.94.0 GNU, with the bundled Rust LLD configuration used for native execution. No elevation, Developer Mode, permission repair, global Git settings, OS-protection changes, or test-source/assertion changes were used for the bounded rerun. Failed fixtures were retained; no owned test processes or database/API listeners remained afterward.

Published evidence, pinned to PR #307 commit 05e302c.

Suggested diagnostic distinction: record the specific native-manager setup error, toolchain, fixture path, and permission capabilities before grouping these failures with scheduling timeouts. No request to weaken the private-directory checks, widen timeouts, or treat isolated passes as a release gate.

[afateen]

I am taking a bounded test-fixture investigation in parallel with the independent #81 source-diff tool. Source pin: 30ec3fa. The latest local #136 repository gate reproduced issue190_late_stop_cancels_held_ack_without_acceptance_or_post_verifier_seal timing out in the runner suite, then passing unchanged in isolation; that is not a causal finding or green full-suite result. I will use source-bound baseline/candidate checks to identify and, if reproduced, fix fixture readiness/resource contention. No skipped assertions, blanket timeout increases, production safety weakening, privilege changes or repeat-until-green claims. The separate Windows symlink capability failures remain explicit. @dstkwll: scope is test-fixture reliability, not #294 cache behavior or its production checkpoint changes. No retained services, application databases or provider inference will be used.