tests: serialize process-heavy Windows CI suites (#18943)

## 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`](https://github.com/openai/codex/blob/731b54d08fb93aec31fb020999a62447886f3ab3/codex-rs/app-server/tests/common/mcp_process.rs#L244-L263),
but never printed the matching stdout read from
[`read_jsonrpc_message`](https://github.com/openai/codex/blob/731b54d08fb93aec31fb020999a62447886f3ab3/codex-rs/app-server/tests/common/mcp_process.rs#L1123-L1128).
The server initialize handler is a small bookkeeping/response path
([`message_processor.rs`](https://github.com/openai/codex/blob/731b54d08fb93aec31fb020999a62447886f3ab3/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.
This commit is contained in:
Michael Bolin
2026-04-21 21:14:45 -07:00
committed by GitHub
Unverified
parent 0e39614d87
commit faed6d5c07
+17
View File
@@ -8,6 +8,11 @@ max-threads = 1
[test-groups.app_server_integration]
max-threads = 1
[test-groups.core_apply_patch_cli_integration]
max-threads = 1
[test-groups.windows_sandbox_legacy_sessions]
max-threads = 1
[[profile.default.overrides]]
# Do not add new tests here
@@ -27,3 +32,15 @@ test-group = 'app_server_protocol_codegen'
# Keep the library unit tests parallel.
filter = 'package(codex-app-server) & kind(test)'
test-group = 'app_server_integration'
[[profile.default.overrides]]
# These tests exercise full Codex turns and apply_patch execution, and they are
# sensitive to Windows runner process-startup stalls when many cases launch at once.
filter = 'package(codex-core) & kind(test) & test(apply_patch_cli)'
test-group = 'core_apply_patch_cli_integration'
[[profile.default.overrides]]
# These tests create restricted-token Windows child processes and private desktops.
# Serialize them to avoid exhausting Windows session/global desktop resources in CI.
filter = 'package(codex-windows-sandbox) & test(legacy_)'
test-group = 'windows_sandbox_legacy_sessions'