@@ -110,20 +110,26 @@ server-process-serial = { max-threads = 1 }
110110
111111[profile .ci ]
112112# CI inherits the default profile (cluster group, threads-required,
113- # slow-timeout) and adds:
114- # - more retries: CI runners are ~2× slower per-core than dev
115- # workstations, so the cluster tests' in-test `wait_for`
116- # budgets are proportionally tighter. Three retries (four total
117- # attempts) buys headroom for jitter without papering over real
118- # regressions — a genuinely broken test fails four times in a row.
119- # - JUnit XML: picked up by the workflow's artifact upload.
113+ # slow-timeout) and adds retries + JUnit XML.
114+ #
115+ # Retries are scoped, not blanket. The bulk of the suite (unit tests +
116+ # single-node server tests) is deterministic; the ONE non-cluster flake
117+ # source is the rare ephemeral-port reuse race in the `server-process`
118+ # group, which a single retry covers. So the profile-wide retry is just
119+ # `count = 1` (two attempts). A blanket high count here is worse than
120+ # useless: nextest resolves retries per-test with overrides winning over
121+ # the profile-wide value, so a high number here never even reached the
122+ # cluster tests (their `default` override pins count = 2) — it only
123+ # multiplied the timeout tail of every slow single-node server test by
124+ # 4×. The cluster tests get their genuine CI headroom from the dedicated
125+ # override below instead.
120126#
121127# NOTE: we deliberately do NOT bump `slow-timeout` here. The
122128# slow-timeout only controls when nextest gives up on a stuck
123129# *process*; it does NOT extend the test's internal `wait_for`
124130# budgets. Once a `wait_for` panics, the test has already failed —
125131# making nextest wait longer just wastes CI minutes on cleanup.
126- retries = { backoff = " fixed" , count = 3 , delay = " 2s" }
132+ retries = { backoff = " fixed" , count = 1 , delay = " 2s" }
127133fail-fast = false
128134
129135# Four cluster tests are excluded from the CI profile ONLY. They still run under
@@ -157,5 +163,16 @@ not (
157163)
158164"""
159165
166+ # CI-only cluster headroom. On CI runners (~2× slower per-core than a dev
167+ # workstation) the cluster tests' in-test `wait_for` budgets are proportionally
168+ # tighter, so 3-node bring-up jitter needs more retry headroom than the
169+ # `default` profile's count = 2. Four attempts absorbs startup jitter without
170+ # hiding regressions — a genuinely broken test fails four times in a row. This
171+ # `ci`-profile override is checked before the `default`-profile cluster override
172+ # and so wins under `--profile ci`; local `cargo nextest run` still gets count = 2.
173+ [[profile .ci .overrides ]]
174+ filter = ' package(nodedb-cluster-tests)'
175+ retries = { backoff = " fixed" , count = 3 , delay = " 2s" }
176+
160177[profile .ci .junit ]
161178path = " junit.xml"
0 commit comments