This is an automated email from the ASF dual-hosted git repository.

chenBright pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/brpc.git


The following commit(s) were added to refs/heads/master by this push:
     new a4ddf971 test: bump brpc_channel_unittest to size=large (900s) (#3339)
a4ddf971 is described below

commit a4ddf9716da6af292dc100a2e6e061e07f77becd
Author: rajvarun77 <[email protected]>
AuthorDate: Sat Jun 13 06:18:20 2026 -0400

    test: bump brpc_channel_unittest to size=large (900s) (#3339)
    
    brpc_channel_unittest packs dozens of timing-sensitive TEST_F (backup
    request, retry/backoff, timeouts) into a single binary. On contended CI
    runners its cumulative real-time waits exceed Bazel's default per-test
    300s (size=medium) limit, producing flaky TIMEOUT failures (observed
    TIMEOUT in 4/5 no-cache runs on a GitHub ubuntu-22.04 runner).
    
    Add an optional per_test_size override to the generate_unittests macro
    and set brpc_channel_unittest to size=large (900s). No test source changes.
    
    Sharding was rejected: the binary's TEST_F share fixed loopback endpoints
    and global state, so parallel shards make a 'connection refused' test
    observe another shard's live server and fail deterministically.
    
    Co-authored-by: rajvarun77 <[email protected]>
    Co-authored-by: Claude Opus 4.8 (1M context) <[email protected]>
---
 test/BUILD.bazel            | 13 +++++++++++++
 test/generate_unittests.bzl | 19 ++++++++++++++++++-
 2 files changed, 31 insertions(+), 1 deletion(-)

diff --git a/test/BUILD.bazel b/test/BUILD.bazel
index d536197a..13ef5922 100644
--- a/test/BUILD.bazel
+++ b/test/BUILD.bazel
@@ -259,6 +259,19 @@ generate_unittests(
     per_test_tags = {
         "brpc_redis_unittest.cpp": ["external", "local"],
     },
+    # brpc_channel_unittest packs dozens of timing-sensitive TEST_F (backup
+    # request, retry/backoff, timeouts) into one binary whose cumulative
+    # real-time waits exceed Bazel's default per-test 300s (size=medium) limit
+    # on contended CI runners, causing TIMEOUT failures. Raise its limit to
+    # size=large (900s).
+    #
+    # NB: do NOT shard this binary. Its TEST_F share fixed loopback endpoints
+    # and global state; running shards as parallel processes makes a
+    # "connection should be refused" test observe another shard's live server
+    # on the same port and fail. size=large is the only safe lever here.
+    per_test_size = {
+        "brpc_channel_unittest.cpp": "large",
+    },
 )
 
 refresh_compile_commands(
diff --git a/test/generate_unittests.bzl b/test/generate_unittests.bzl
index 8cfec78a..5232fbd6 100644
--- a/test/generate_unittests.bzl
+++ b/test/generate_unittests.bzl
@@ -13,10 +13,26 @@
 # See the License for the specific language governing permissions and
 # limitations under the License.
 
-def generate_unittests(name, srcs, deps, copts, linkopts = [], data = [], 
per_test_tags = {}):
+def generate_unittests(
+        name,
+        srcs,
+        deps,
+        copts,
+        linkopts = [],
+        data = [],
+        per_test_tags = {},
+        per_test_size = {}):
     tests = []
     for s in srcs:
         ut_name = s.replace(".cpp", "")
+        # per_test_size raises Bazel's per-test timeout for a specific file
+        # ("large" = 900s vs the default medium = 300s), for binaries whose
+        # cumulative real-time waits would otherwise blow the limit on
+        # contended CI runners.
+        kwargs = {}
+        size = per_test_size.get(s)
+        if size != None:
+            kwargs["size"] = size
         native.cc_test(
             name = ut_name,
             srcs = [s],
@@ -29,6 +45,7 @@ def generate_unittests(name, srcs, deps, copts, linkopts = 
[], data = [], per_te
             # pass, and "local" runs them outside the sandbox so the 
PATH-located
             # server binary is visible and loopback works.
             tags = per_test_tags.get(s, []),
+            **kwargs
         )
         tests.append(":" + ut_name)
 


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to