mirror of
https://github.com/OrcaSlicer/OrcaSlicer.git
synced 2026-07-15 06:50:35 +00:00
9e8ac03476
The FilamentGroup property/golden harness checked a per-extruder max_group_size cap unconditionally in check_constraints. That cap is an invariant of the flush-partition solvers only (calc_group_by_enum / calc_group_by_kmedoids, reached via calc_filament_group_for_flush), which partition filaments subject to each extruder's capacity. MatchMode (calc_filament_group_for_match) does not partition by capacity: it maps every filament to the extruder holding the nearest-color loaded AMS filament, and its solver capacity is the used-filament count, not max_group_size (FilamentGroup.cpp:1067). So a legitimate MatchMode result can place more than max_group_size filaments on one extruder. The prop_a/b/c_mode_match specs run MatchMode, and their scenarios are generated with std::uniform_int_distribution / std::shuffle, which are implementation-defined. For a fixed mt19937 seed, libc++ (macOS), libstdc++ (Linux) and MSVC (Windows) draw different scenarios, so the CI failure only surfaced on Linux/Windows while macOS passed. Verified locally: 248/600 config-A MatchMode seeds exceed the cap under libc++ — it is reachable everywhere; seed 90400 just isn't an exceeding draw on macOS. Gate section 3 on FGMode != MatchMode. No test case is removed or skipped: all 57 FlushMode specs still assert the cap, MatchMode still asserts the unprintable-filament/volume correctness constraints (which it honors), and MatchMode grouping regressions are still caught by the golden score gate at 3% tolerance. Test-only change; slicing behavior and g-code are unaffected.