Addresses BF-45263.

Problem

disagg_replica_sets_kill_secondary_jscore_passthrough shard _4 on build variant enterprise-amazon2023-linux-x86-debug-tsan ("* TSAN Enterprise Amazon 2023 Linux x86 disagg-storage-services DEBUG (Replica Sets)") in the mongodb-mongo-v9.0-staging project is killed by the Evergreen 2h exec timeout roughly 14% short of completing. It has timed out on 4 of 4 recent nightly runs (2026-07-15 through 2026-07-24: BFG-3422890, BFG-3446093, BFG-3462404, BFG-3463175).

The variant runs a ThreadSanitizer debug binary (--config=dbg_tsan --opt=on --fission=no), but its expansions: block sets no exec_timeout_secs and no exec_timeout_factor, so it inherits the 2h project default — a budget sized for much faster builds.

Verified at the failing revision:

git show 36bc71b1:etc/evergreen_yml_components/variants/sanitizer/test_dev.yml
# variant block at lines 528-552 — no timeout key of any kind

The same file already uses these keys elsewhere, so the mechanism is established practice here — this variant simply does not use it:

• exec_timeout_factor: 1.5 / idle_timeout_factor: 1.5 in the shared variables: anchors (lines 79-80, 265-266)
• exec_timeout_secs: 32400 + timeout_secs: 18000 on enterprise-rhel8-arm64-dynamic-spider-monkey-dbg (lines 1195-1196)

Evidence that the budget — not a hang — is the constraint

resmoke ran 1h57m57.98s and was cancelled mid-suite while still making normal progress; the test preceding the cutoff completed cleanly 3 seconds earlier.

[2026/07/24 18:34:26.855] [executor:js_test:job0] 2026-07-24T22:34:26.854Z Running timeseries_hint_id.js...
[2026/07/24 18:34:29.600] Hit exec timeout (2h0m0s).
[2026/07/24 18:34:29.729] Finished command 'subprocess.exec' ('execute resmoke tests') in function 'run generated tests' (step 3.24 of 3) in 1h57m57.982444024s.

[2026/07/24 18:34:58.265] [executor] 2026-07-24T22:34:58.265Z Summary of latest execution: 1382 test(s) ran in 7101.86 seconds (1378 succeeded, 56 were skipped, 2 failed, 2 errored)

Counting Running <name>.js... lines against the echoed suite roster: 249 of ~290 js tests started (~41 remaining, ~14%). At the observed ~28.4 s per js test (including hooks), the shard needs about 19 more minutes — roughly 2h20m total.

Further corroboration: the four timeouts stopped at different tests (timeseries_compound_mismatched_sort_index.js, api_version_unstable_indexes:CleanEveryN, timeseries_hint_id), which is what a wall-clock ceiling predicts and what a single pathological hanging test would not.

Note for anyone reading the BFG data: the "failing tests" listed on those BFGs (job*_fixture_teardown etc.) all ran in the AFTER_TIMEOUT phase, and the Process exited with code -6 entries are the hang analyzer's SIGABRT — both are post-timeout collateral, not causes.

Proposed change

Add a timeout override to the variant's expansions: block in etc/evergreen_yml_components/variants/sanitizer/test_dev.yml on the v9.0-staging branch:

# variant: enterprise-amazon2023-linux-x86-debug-tsan
expansions: &enterprise-amazon2023-linux-x86-debug-tsan-expansions
  exec_timeout_secs: 10800 # 3h — TSAN debug shard needs ~2h20m (BF-45263)
  timeout_secs: 7200 # 2h idle

10800 gives roughly 28% headroom over the measured ~2h20m. exec_timeout_factor: 1.5 (the idiom used by the variables: anchors in the same file) is an equivalent alternative reaching the same 3h.

Alternative / complement

If a 3h nightly task is undesirable, increase the shard count for this task on this variant instead so each shard fits inside 2h — shard _4 currently carries ~290 js tests, and one additional shard brings it to ~2h. The timeout bump is preferred as the first step: one line, and it does not perturb other variants' generated configs.

Ownership note

The variant block was introduced by SERVER-126440 (Query Integration) and descends from the original disagg TSAN build added in SERVER-123793 (Replication); the failing task itself is generated from n_jscore_passthrough_gen under etc/evergreen_yml_components/tasks/resmoke/server_divisions/durable_transactions_and_availability/tasks.yml. Assigned here to Server Programmability per triage direction — please re-route if another team is the better owner for this variant's CI configuration.

Out of scope

A separate, independent defect was found in the same task log and should get its own DevProd ticket rather than being fixed here: the Evergreen S3 service account arn:aws:iam::557821124784:user/srv-evg-mongodb-mongo-s3-key lacks s3:ListBucket on arn:aws:s3:::mciuploads, causing 403s on binary and plugin downloads. It cost only ~2 minutes of the budget and did not cause the timeout.

Testing

Confirm a full green run of disagg_replica_sets_kill_secondary_jscore_passthrough on enterprise-amazon2023-linux-x86-debug-tsan in mongodb-mongo-v9.0-staging after the change, and verify the shard's reported wall-clock lands comfortably below the new budget.

If the task still times out with progress stalled at a single test for many minutes, that would refute the undersized-budget diagnosis and indicate a genuine hang instead — investigate as a separate issue.

Filed from an AI-generated triage of BF-45263 (the bf-triage skill); the analysis above is not yet human-reviewed.