The filament-group golden harness landed with H2C/A2L support (#14685). Its
"FilamentGroup golden regression" / stress_66 case fails intermittently on
Windows x64, on main and on unrelated PRs alike. The test depends on how fast the
runner is.
The k-medoids clustering these goldens exercise is an anytime search bounded by a
3 second wall clock. Every restart is seeded from its own index, so nothing about
it is random. What varies is how many restarts fit in the budget, and the best
cost is a minimum over completed restarts, so a slower runner is never better.
Grading a score produced that way measures the machine as much as the code.
Add a ClusteringBudget struct and let the tests set it. The defaults are the
current 3 seconds and 30 restarts, so slicing behavior is unchanged. A
non-positive timeout removes the wall clock and bounds the search by restart
count alone.
The goldens are then graded under a fixed budget of four restarts, where every
one of them reaches the BambuStudio reference within 3%, so the score becomes a
property of the code. This retires the machine-specific 125103 lock on stress_66.
The default wall-clock path keeps its own test, asserting the grouping is valid
and the search does not run away. It makes no score assertion, because under a
wall clock that number is not a property of the code.
The golden test also checks the run fits in ten times the default wall clock.
Slicing quality depends on how many restarts fit in the budget, so a search an
order of magnitude slower would degrade real groupings while a fixed-budget score
gate stayed green.
The 3% tolerance stays as the parity allowance against the goldens. It also
covers a small spread across standard libraries: the k-medoids search seeds each
restart with std::shuffle, whose algorithm the C++ standard leaves unspecified,
so libstdc++, libc++ and the MSVC STL permute the same seed differently, start
from different medoids, and settle on slightly different groupings, about 3e-4
apart and only on the goldens heavy enough to reach the k-medoids search.
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.
