Files
bambuddy/backend
maziggy 5772523003 fix(backup): stop two backed-up K-profiles claiming one live slot (#2656)
`_match_kprofile` ends in a single-candidate fallback, and the per-nozzle
    loop called it once per entry with no record of which live profiles were
    already taken. Two backup entries sharing a `filament_id` and matching on
    neither `setting_id` nor `name` both resolved to the same live profile, both
    got the same `cali_idx`, and both went into the batch — so the second
    overwrote the first on the printer while the tally counted two restored.

    Reachable in the ordinary way: the user deletes one of a pair after the
    backup, and the delete-then-add re-key this code already reasons about is
    exactly what strips the `setting_id` match.

    Fix: thread a `claimed` set of slot ids through the loop; a live profile can
    only stand in for one entry. A displaced entry falls through to
    `cali_idx: -1` — add-as-new is the safe outcome — and folds into the
    existing `kprofilesUnmatched` note rather than earning a new code.

    The single-candidate fallback is still judged against every candidate rather
    than the unclaimed ones. Two live profiles for one filament are ambiguous
    whether or not another entry has taken one, and narrowing to "available"
    would turn a guess the code deliberately refuses into a match.

    Tests: 2 regression (the displaced entry is added rather than aliased, and
    keeps its own setting_id) + 2 controls (two genuine matches keep their own
    slots; a claimed slot does not make an ambiguous pair matchable). Both
    regressions confirmed failing against the pre-fix service.
2026-08-15 14:14:30 +02:00
..