mirror of
https://github.com/rustfs/rustfs.git
synced 2026-09-06 03:59:14 +00:00
394394cdfc
Six set_disk::ops tests failed non-deterministically only under concurrent full-suite load, rotating between runs while each passed in isolation. All six share one root cause: a lock-owning put_object quorum-acks once the rename fanout reaches write quorum and lets a detached tail task finish the lagging disks, so a fixture that inspects per-disk state immediately after PUT can observe a disk the tail has not reached yet. The two heal report fixtures, the inline-commit fixture, and the transaction-fencing fixture read or delete physical shards right after PUT, and hit FileNotFound on a lagging disk. The two metadata-cache fixtures prime the cache after PUT, and the read fanout refuses to publish a cache entry while any disk still reports an error, so the priming read observably published nothing. Keep every affected setup PUT on the full-fanout commit path with no_lock: true, following the existing precedent in this module, so PUT returns only after every disk has committed. The option only governs lock acquisition, so it does not weaken what any of these fixtures assert; the transaction-fencing gate in particular is driven by the fleet proof and env vars, never by the lock option. Where a fixture also depends on cache publication, re-prime until the current generation is observably cached instead of asserting on a single read that a loaded host can stall past the cache TTL. The heal race fixture's shard damage injection is best-effort by construction, so it now skips injection when the previous round's tail still lags rather than unwrapping a read that may legitimately race. No production code changes, and no retries or sleeps added.