2 Commits

Include renames

Author	SHA1	Message	Date
maziggy	5d6d928b3f	fix(virtual-printer): #1429 net.info[*].ip cache leak + mode wire-value rename ... #1429 (reported by @TrickShotMLG02, confirmed by @Mape6 on a flat single-LAN that rules out subnet / mDNS-reflector theories): with the physical printer off the slicer's "Send" landed in Bambuddy's archive; once the printer powered on every subsequent "Send" went straight to the printer's SD card and bypassed Bambuddy. Bundle analysis: mape6-before showed clean FTP receive + archive lines, mape6-after had zero FTP attempts to Bambuddy once the printer was online. Cause: mqtt_bridge.py::_resolve_client encoded _target_ip_uint32_le / _vp_ip_uint32_le ONLY on client-identity change and early-returned on every refresh tick when the same client object was still bound. If target_client.ip_address was empty at first bind (DB row stale, or client constructed before SSDP refresh filled it in), the encoding stayed None, the net.info[*].ip rewrite block was skipped, the cache filled with the real printer IP, sticky-key preservation kept the poisoned net value alive across every subsequent incremental push, and the slicer followed the leaked IP. Only Bambuddy-restart-with-printer-off cleared it — the workaround both reporters independently arrived at. Same shape on multi-NIC printers (X1C, H2D Pro): the rewrite only matched entries whose ip equalled _target_ip_uint32_le, so a secondary interface IP Bambuddy never saw would leak through unchanged. Bridge fix: - _resolve_client calls a new _refresh_ip_encoding() on every refresh tick, even when client identity is unchanged; self-heals once ip_address becomes valid. - _refresh_ip_encoding() sweeps the existing _latest_print_state when encoding becomes valid for the first time. Without the sweep, sticky-key preservation keeps the pre-arm poisoned cache alive forever — incremental pushes that don't include net carry the bad value forward. - _rewrite_net_info_ips() rewrites EVERY non-zero net.info[].ip entry that doesn't already equal the VP IP, not just entries matching _target_ip_uint32_le. Multi-NIC printers stop leaking secondary interfaces. Zero-IP placeholders are left alone so "active interface" detection still works. - INFO logging on encoding arm/update and on cache sweep so future bundles directly answer "did the rewrite fire?". Mode wire-value rename (#1429 follow-up, separate confusion source): - Both reporters' support bundles showed mode: immediate while the UI said "Archive"; @TrickShotMLG02 quoted: "I have no idea why it says immediate in the support-info.json file. In the webui the printer is set to archive". UI button "Archive" had always saved immediate, and "Queue" had always saved print_queue. Canonical wire values are now archive / review / queue / proxy, matching the button labels 1:1. - New normalize_vp_mode() + VP_MODE_* constants in models/virtual_printer.py; manager.py normalises on construction so a legacy row read pre-migration still dispatches correctly. - core/database.py::run_migrations rewrites existing virtual_printers and settings rows; idempotent (re-runs are no-ops); identical SQL under SQLite and Postgres. - API routes accept both legacy and canonical on input, normalise before storage. GET /settings/virtual-printer normalises on read so the frontend's mode-button highlight works for stale legacy values. - Three frontend VP components (VirtualPrinterSettings, VirtualPrinterCard, VirtualPrinterAddDialog) switched click handlers and type aliases to canonical; each got its own normalizeMode() helper so a stale-cached settings payload still highlights the right button. Two pre-existing `printer.mode === 'queue' ? 'review'` legacy mappings in VirtualPrinterCard were the source of a test failure caught mid-implementation where the new canonical 'queue' was being mis-aliased back to 'review' and hiding the auto-dispatch + force-color-match toggles. mode handler is NOT the dispatch bug: manager.py::_archive_file (the handler for archive mode) doesn't dispatch to the physical printer. The "files end up on the printer's SD card" symptom was the IP-leak from the bridge cache. The mode rename is purely clarity / support- bundle accuracy.	2026-06-02 14:33:20 +02:00
maziggy	6bc6a1d683	feat(virtual-printer): setup diagnostic + one-click slicer-certificate export ... Two recurring virtual-printer support pains, both on the Virtual Printers settings page. Setup check: a stethoscope action on each VP card runs a pass/fail/warn/skip checklist — VP enabled, services running, bind interface still exists, access code set, target printer (proxy mode), and a live TCP probe of the FTP / MQTT / discovery ports on the bind IP. start_server swallows per-service bind errors, so a service object can exist while nothing is listening; probing the bind IP from outside is the only reliable signal and it catches the common "VP not visible in the slicer" bind-IP-conflict and stale-interface cases. Slicer certificate: virtual printers present a TLS cert signed by a shared CA the slicer must trust. Until now users had to docker exec in and cat bbl_ca.crt. A "Slicer certificate" row on the settings card now offers Copy and Download (bambuddy-virtual-printer-ca.crt) plus the SHA-256 fingerprint. GET /virtual-printers/ca-certificate returns only the public certificate; the CA private key never leaves the backend. The CA is generated on demand so the button works before the first VP is enabled. Backend: - services/virtual_printer/diagnostic.py — run_vp_diagnostic + port probes - schemas/virtual_printer.py — VPDiagnosticResult - CertificateService.get_ca_certificate_info() + manager helper - routes: GET /virtual-printers/ca-certificate, /{vp_id}/diagnostic Frontend: - VirtualPrinterDiagnosticModal.tsx; stethoscope button on VirtualPrinterCard - caCert row on VirtualPrinterList; utils/clipboard.ts (shared copy w/ non-secure-context fallback + downloadTextFile), de-duplicating the existing FQDN-copy logic - vpDiagnostic.* + virtualPrinter.caCert.* across all 9 locales 9 backend unit tests + 4 route integration tests + 6 frontend tests. Backend ruff clean, frontend build clean, i18n parity green.	2026-05-22 13:24:35 +02:00