From 65f7f64ae5524955c2f283a21397cb1f23195f0c Mon Sep 17 00:00:00 2001 From: Ahmed Ibrahim <219906144+aibrahim-oai@users.noreply.github.com> Date: Tue, 17 Mar 2026 03:54:03 +0000 Subject: [PATCH] Record validation pass 1 Co-authored-by: Codex --- .codex/flaky-test-triage.md | 1 + 1 file changed, 1 insertion(+) diff --git a/.codex/flaky-test-triage.md b/.codex/flaky-test-triage.md index 231e66f44c..9c9bd74a50 100644 --- a/.codex/flaky-test-triage.md +++ b/.codex/flaky-test-triage.md @@ -120,3 +120,4 @@ Older failures also appeared on Linux, but the repeated cross-PR signal is stron | `27654cc6d` | Merge `origin/main` into flaky-test branch | failed | Run `23172240730` exposed a branch-local `Argument comment lint` failure in the new test-only `spawn_thread` wrappers. Local reproduction with `./tools/argument-comment-lint/run.sh` showed those wrappers needed explicit argument comments for `persist_extended_history`, `metrics_service_name`, `parent_trace`, and `user_shell_override`. The same stale run later surfaced two Windows x64 shell-command regressions, `recognizes_safe_powershell_wrappers` and `accepts_full_path_powershell_invocations`, caused by the PowerShell parser timeout refactor inheriting stdin instead of matching `Command::output()`. `Bazel (experimental)` run `23172240729` also failed on the two Linux shards on this stale SHA, so the next follow-up combines the lint cleanup with the minimal stdin fix and retriggers the full matrix. | | `c14493260` | Fix Windows PowerShell parser stdin | failed | Run `23173027099` cleared the stale lint and `codex-shell-command` parser regressions, and `Bazel (experimental)` run `23173027042` finished green. The only remaining failures were `Tests — windows-x64 - x86_64-pc-windows-msvc` and `Tests — windows-arm64 - aarch64-pc-windows-msvc`, both in `all::suite::apply_patch_cli::apply_patch_cli_can_use_shell_command_output_as_patch_input`. CI annotations showed the `cmd.exe`-wrapped nested `powershell.exe -Command "Get-Content ..."` invocation printed the command string literal instead of reading the file, so the next follow-up replaces that nested command with a UTF-8 `-EncodedCommand` script. | | `6a302cb2e` | Encode Windows apply_patch read command | failed | Run `23176240418` kept all non-Windows jobs and `Bazel (experimental)` green, but both Windows `Tests` shards still failed in `all::suite::apply_patch_cli::apply_patch_cli_can_use_shell_command_output_as_patch_input`. Check-run annotations `67338924441` and `67338924464` showed the nested `powershell.exe` read was now executing, but it appended `CLIXML` progress output (`Preparing modules for first use.`) after the expected file contents. The next follow-up suppresses PowerShell progress records, uses `[System.IO.File]::ReadAllText(...)`, and adds `-NonInteractive` so the shell tool output stays deterministic. | +| `4a3181290` | Suppress PowerShell CLIXML in apply_patch test | full pass | Runs `23176985939` (`rust-ci`) and `23176985980` (`Bazel (experimental)`) finished green for the full PR, including both Windows `Tests` jobs. The Windows `cmd.exe` harness now keeps the nested UTF-8 PowerShell read but suppresses progress records, switches to `[System.IO.File]::ReadAllText(...)`, and adds `-NonInteractive` so the shell tool returns only the source bytes. This is pass 1 of 5 after the latest failing run. |