Three Bambu Lab catalog rows share #FFFFFF — Jade White (PLA Basic),
Ivory White (PLA Matte), White (PLA Silk). The catalog lookup in
create_spool_from_tray filtered by manufacturer + hex only with no
ORDER BY, so SQLite returned rows in rowid order and the first-inserted
entry (Jade White) won every RFID-driven spool creation regardless of
the actual material the AMS reported. Inserting an Ivory White PLA
Matte roll always produced a spool named "Jade White".
Same class of bug bites any other shared-hex pair across PLA Basic /
Matte / Silk; the whites were just the most visible.
Fix: add a material filter using tray_sub_brands (the printer-reported
material variant — "PLA Matte" / "PLA Basic" / "PLA Silk"), which
matches the catalog's `material` column directly. Use the raw
tray_sub_brands value (captured before the gradient/dual/tri-color
subtype upgrade) because the catalog stores "PLA Basic" for gradient
rolls too — the upgraded subtype lives on the spool, not the catalog.
Also add ORDER BY id to the query so the fallback path (empty
tray_sub_brands — third-party spools / OpenTag tags) is deterministic
across SQLite + PostgreSQL instead of DB-implementation-defined.
Tests: 4 new in test_spool_tag_matcher.py — Ivory White PLA Matte
resolves to Ivory not Jade (the regression pin), PLA Silk White
resolves to White, Jade White PLA Basic still works with all three
#FFFFFF entries seeded, and the empty-sub_brands fallback stays
deterministic via the new ORDER BY.
Existing spools already mis-named in the database don't auto-correct
on next AMS read — the matcher only fires on new RFID-driven creation.
Affected users need a manual rename in Inventory after upgrading.
maziggy
972e635233