mirror of
https://github.com/rustfs/rustfs.git
synced 2026-09-06 03:59:14 +00:00
af896dc427
* test(ecstore): retain final decommission capacity snapshot override take_decommission_capacity_info_override_for_test used to pop the queue to exhaustion, after which get_decommission_all_pool_capacity_infos silently fell back to the host's real statfs numbers. Any new sampling point added to the decommission start paths re-introduced that host dependency and broke tests on some dev machines (#6989 patched one instance by topping up snapshot counts, but the coupling remained). Keep the final queued snapshot and replay it for every subsequent sample so tests always observe injected capacity once an override is installed. All existing injection patterns (single snapshot, repeated identical snapshots, decreasing sequences ending at the post-operation state) keep their semantics. * test(ci): serialize load-sensitive heal and cache-generation tests Under a heavily parallel nextest run (~792 ecstore tests), two tests of set_disk::ops::heal::heal_result_report_tests failed nondeterministically per round (different members each time; all 29 pass standalone). Every test in the module builds a TempDir-backed 4-disk hermetic erasure set and drives MiB-scale writes plus deep-scan heal: under load a single disk's IO can fail while write quorum still holds, flipping per-disk readback and aggregate-outcome assertions. The module's #[serial] markers do not serialize across nextest's process-per-test boundary. Verification also caught complete_multipart_generation_retires_cached_snapshot failing once under the same load; it and its object.rs sibling carry #[serial(metadata_cache_invalidation_probe)] and assert get_object_metadata_cache generation semantics - the same shape that forced the transition matrix tests into the serial group. Add both families to the ecstore-serial-flaky test-group in the default and ci profiles. Preventive serialization only, no retries. Three full parallel rounds after the change: 792/792 passed each round.