When a collection gets a new index, one machine builds the full-corpus copy. That can take 40 minutes at a million vectors. Meanwhile the auto-tuner is continuously running small experiments across the fleet, looking for a better index configuration, and it decides where to send them by asking who has capacity.
The builder answered that question wrong. It reserved disk space for the artifact it was about to produce, and nothing else. It never reserved any measure of EFFORT. So a machine 40 minutes into the heaviest job we run reported itself as having a completely free schedule, and the tuner did the sensible thing with that information: it kept sending experiments. The build got slower, the experiments got slower, and the machine that looked idlest in the fleet was the busiest one in it.
The fix is small and the interesting part is where the cost gets computed. A build now reserves effort as well as bytes, priced at the collection's real size rather than at the small reference scale we quote strategy costs in. That pricing has to happen when the reservation is TAKEN, not when it's released, because a scale-dependent charge can't be reconstructed after the fact -- the reservation has to carry its own price. It ends up mirroring how the byte reservation already worked, keyed by machine, collection, and strategy.
There was a second defect on the same path, found while fixing the first. The rule that a machine should only run one full-corpus build at a time was written down in the code's own documentation and enforced nowhere. What existed was narrower: it serialized builds within a single promotion decision. Two independent decisions arriving at once -- an operator activating an index while the auto-promoter fired -- each dispatched immediately, and neither knew about the other. Now a builder with a full-corpus build already in flight gets the new one appended to a chain behind it.
Verification, since this is a scheduling claim and scheduling claims are easy to assert and hard to believe. Across two complete build windows in production, 39 and 59 minutes, with the tuner fully enabled the whole time: zero experiments landed on the machine doing the build. The other machine took 56 and 44. That is what it looks like when a system can finally see its own work. The chaining fix is a different story -- it's unit-tested, and it prevents the exact collision it would need in order to be observed in the wild, so it stands on its tests rather than on a production sighting.
Two dead ends got ruled out before any of this, and they're written down so nobody re-walks them: reclassifying vamana as an expensive strategy, and repricing the general build cost at full scale. Both are reasonable-sounding, both would have changed nothing, because the path in question wasn't consulting the effort budget at all.