Background

jstests/concurrency/fsm_workloads/timeseries/timeseries_upgrade_downgrade_with_crud.js runs in the concurrency_sharded_replication_rate_limited suite, which injects the failIngressRequestRateLimiting failpoint on the shards (activationProbability 0.25). Under load shedding, operations can be rejected with error 462 / IngressRequestRateLimitExceeded.

Reads are currently not marked idempotent (see ErrorLabelBuilder::isOperationIdempotent(), gated on SERVER-108898, which is not planned), so a shed read is returned to the client labeled SystemOverloadedError without RetryableError. It is therefore not retried by mongos and surfaces directly to the shell. Writes can also surface 462 in the case where mongos exhausts its internal retries. The workload does not tolerate 462 in any state, so the thread throws and the test fails.

This is tracked failing in BF-44699. All observed occurrences are in the find state, but the aggregate and countDocuments read states are equally exposed, and the write states can hit it too when internal retries are exhausted.

Work

Make the workload tolerate IngressRequestRateLimitExceeded (462) as an accepted/transient error across its states (reads and writes), consistent with the existing handling of InterruptedDueToTimeseriesUpgradeDowngrade and QueryPlanKilled. This is durable expected behavior in the rate-limited suite (not a stopgap for SERVER-108898).