viewit
2b2d5ee0a7
Found during a targeted code review, not from a user report. parse_profile()'s `name` field went straight through clean_name() without routing through first_str() first, unlike filament_vendor/filament_type/ default_filament_colour right below it - all of which handle the documented case where OrcaSlicer stores a field as ["value"] instead of a plain string. If `data["name"]` was ever a list, clean_name()'s re.sub() raised TypeError since it requires a string argument. Fixed by routing it through first_str() like its neighbors. Also added a debug log when sys_by_name (the system-profile lookup index) overwrites an entry due to a name collision - clean_name() deliberately collapses variant-suffixed profile names (e.g. "...@base" vs "...@Anycubic Kobra X 0.4 nozzle") onto the same cleaned name, so a collision is expected, but the resulting last-write-wins overwrite was previously silent, making an unexpected inherits-parent resolution hard to debug. New tests in tests/test_orca_filaments_parser.py add the first dedicated coverage for parse_profile()/parse_profile_bytes()/clean_name() - previous tests only used pre-parsed profile dicts as fixtures and never exercised the parsing logic itself.
3.2 KiB
3.2 KiB
Changes in this build
- Fix: combined ACE-RFID filament tags (e.g. "GEEETECH PLA Bas" from third-party RFID tools) still weren't auto-matching to imported OrcaSlicer profiles, even after the first attempt at this in a previous nightly — the matching logic was only ever wired into the OrcaSlicer slicer-sync endpoint, never into the actual MQTT status path that feeds the dashboard and Happy-Hare gate data, so the dashboard kept showing the raw unmatched RFID string. Centralized the matching so all three places that resolve a slot's filament profile benefit identically. Also added variant-token disambiguation (e.g. "Bas" vs. "Matte") for when a vendor has multiple profiles of the same material, and fixed a related edge case where a manual per-slot override could be incorrectly treated as stale on an RFID-tagged spool (Issue #101, thanks @Blaim for the extensive debugging that pinpointed this).
- Feat: new setting under Settings → Print — "Delete file from printer after successful print" — automatically removes a GCode file from the printer's own storage once it finishes printing successfully, keeping only the copy in the bridge's own GCode store. Off by default, and only ever applies to files that were uploaded through the bridge itself (so there's always a backup); files started directly from the printer or Anycubic Slicer are never touched.
- Fix: the dashboard could stay stuck showing a printer as online/"ready" indefinitely after it was physically switched off or unplugged, discovered while testing the new smart-plug power-switch feature. Root cause was two-fold: the MQTT socket had no TCP keepalive, so a connection killed without a clean close (unplugged, not a graceful shutdown) could look alive to the OS for 15+ minutes; and even once the dead connection was detected, the status poll loop could get stuck waiting on a reconnect attempt that was already running elsewhere, so it never reached the code that flips the dashboard to "offline". Live-tested against a real printer, including that no sockets, threads, or file descriptors are left behind across repeated disconnect/reconnect cycles — a disconnected printer is now detected and reflected on the dashboard within about 15 seconds.
- Fix: a range of smaller robustness issues found in an internal code review — a single malformed MQTT message from the printer could get permanently stuck at the front of the receive buffer and force a reconnect on every subsequent poll; concurrent requests of the same type could occasionally have their responses mixed up; the camera stream could leak an orphaned ffmpeg process after a printer reboot rotated its stream URL while a new stream was already starting;
/api/settingsand/api/update/applyreturned an unhandled server error instead of a clean "invalid request" for a malformed request body; a typo'd numeric value inconfig.ini(e.g. a stray character in the port number) could prevent the bridge from starting at all instead of falling back to the default; and a rare filament-profile-name collision during import is now logged instead of silently resolved. None of these were reported as user-facing bugs — added as defense-in-depth after a targeted review, with new tests covering each case.