From 9881dc7306dbfe22b34157e6e47de2b1ae45d527 Mon Sep 17 00:00:00 2001
From: Michael Bolin <mbolin@openai.com>
Date: Sat, 25 Apr 2026 16:34:06 -0700
Subject: [PATCH] fix: restore 30-minute timeout for Bazel builds (#19609)

I think raising it to 45 minutes in
https://github.com/openai/codex/pull/19578 was a mistake for the reasons
explained in the comments in the code. Instead, we attempt to defend
against timeouts by increasing the number of shards in
`app-server-all-test` so that a "true failure" that gets run 3x should
not take as much wall clock time.
---
 .github/workflows/bazel.yml     | 9 ++++++---
 codex-rs/app-server/BUILD.bazel | 8 +++++++-
 2 files changed, 13 insertions(+), 4 deletions(-)

diff --git a/.github/workflows/bazel.yml b/.github/workflows/bazel.yml
index bfb10ab6a..ef41330c4 100644
--- a/.github/workflows/bazel.yml
+++ b/.github/workflows/bazel.yml
@@ -17,11 +17,14 @@ concurrency:
   cancel-in-progress: ${{ github.ref_name != 'main' }}
 jobs:
   test:
-    # Ideally, this would be only 30 minutes, but a no-cache-hit Windows build
-    # seems to trip this limit and starting over is painful when it happens.
+    # Even though a no-cache-hit Windows build seems to exceed the 30-minute
+    # limit on occasion, the more common reason for exceeding the limit is a
+    # true test failure in a rust_test() marked "flaky" that gets run 3x.
+    # In that case, extra time generally does not give us more signal.
+    #
     # Ultimately we need true distributed builds (e.g.,
     # https://www.buildbuddy.io/docs/rbe-setup/) to speed things up.
-    timeout-minutes: 45
+    timeout-minutes: 30
     strategy:
       fail-fast: false
       matrix:
diff --git a/codex-rs/app-server/BUILD.bazel b/codex-rs/app-server/BUILD.bazel
index d2d3f42a1..b7ff5b169 100644
--- a/codex-rs/app-server/BUILD.bazel
+++ b/codex-rs/app-server/BUILD.bazel
@@ -5,7 +5,13 @@ codex_rust_crate(
     crate_name = "codex_app_server",
     integration_test_timeout = "long",
     test_shard_counts = {
-        "app-server-all-test": 8,
+        # Note app-server-all-test has a large number of integration tests, so
+        # even a single shard can be quite slow. When there is a legitimate
+        # test failure in a shard, it will still get run 3x in total, which
+        # can cause us to exhaust our CI timeout if the shard happens to run
+        # long. Using a higher shard count for app-server-all-test should help
+        # mitigate this risk.
+        "app-server-all-test": 16,
         "app-server-unit-tests": 8,
     },
     test_tags = ["no-sandbox"],