mirror of
https://github.com/openai/codex.git
synced 2026-04-29 17:06:51 +00:00
faed6d5c07
## Why A [Windows Cargo build](https://github.com/openai/codex/actions/runs/24754807756/job/72425641062) on `main` timed out in several unrelated-looking suites at the same time: - `codex-app-server` account tests failed before account logic, while `mcp.initialize()` was waiting for the first JSON-RPC response. - `codex-core` `apply_patch_cli` tests timed out while running full Codex/apply_patch turns. - `codex-windows-sandbox` legacy session tests timed out while creating restricted-token child processes and private desktops. The app-server log reached the test harness write path in [`McpProcess::initialize_with_params`](731b54d08f/codex-rs/app-server/tests/common/mcp_process.rs (L244-L263)), but never printed the matching stdout read from [`read_jsonrpc_message`](731b54d08f/codex-rs/app-server/tests/common/mcp_process.rs (L1123-L1128)). The server initialize handler is a small bookkeeping/response path ([`message_processor.rs`](731b54d08f/codex-rs/app-server/src/message_processor.rs (L601-L728))), so the failure looks like Windows runner process/pipe scheduling starvation rather than account-specific behavior. ## What Changed This updates `.config/nextest.toml` to serialize two process-heavy sets: - `codex-core` tests matching `package(codex-core) & kind(test) & test(apply_patch_cli)` - `codex-windows-sandbox` tests matching `package(codex-windows-sandbox) & test(legacy_)` `codex-app-server` integration tests were already serialized inside their own package; this change reduces overlap with the other suites that were saturating the runner at the same time. ## Verification - `cargo nextest list --filterset "package(codex-core) & kind(test) & test(apply_patch_cli)"` - `cargo nextest list --filterset "package(codex-windows-sandbox) & test(legacy_)"` The Windows sandbox filter naturally lists no tests on macOS, but it validates the nextest filter/config syntax locally.