Two related queue issues surfaced when scheduling an ASAP print with
quantity > 1 on an H2D:
1. Double-dispatch — both items in the batch ended up in 'printing'
status on the same printer, logged as "BUG: Multiple queue items in
'printing' status for printer N". The scheduler seeded its busy
set empty each tick and relied on _is_printer_idle() reading live
MQTT state, but H2D / P1 series lag several seconds between the
print command and IDLE → RUNNING, so the next check_queue() tick
saw IDLE and dispatched the second batch item onto the already-
running printer. check_queue() now seeds busy_printers with every
printer_id that has a row in 'printing' status before iterating,
so any printer with an outstanding dispatched job is excluded
regardless of what MQTT currently reports.
2. Progress bar flashed 100% — immediately after dispatch the queue
item's per-row progress bar showed the prior print's final mc_percent
for a few seconds, then snapped back to 0% when the new print
started ticking. QueuePage.tsx now gates progress / remaining_time /
layer fields on status.state being RUNNING or PAUSE; in any other
state (FINISH from the prior print, IDLE, PREPARE while heating)
the bar renders at 0% with no stale ETA or layer count.
Regression coverage added in test_phantom_print_hardening.py
(TestBusyPrinterSeedingFromPrintingItems, 3 tests): seeding query
returns only printers with 'printing' rows, empty when none exist,
and end-to-end check_queue() does not call _start_print for a pending
item whose printer already has a 'printing' row even when
_is_printer_idle() is forced True.
In expanded view, PrinterQueueWidget rendered its own "Clear Plate & Start
Next" button inside a yellow-bordered card whenever the plate-clear gate
was up and an auto-dispatch item was queued. PR #939 added the card-level
"Mark plate as cleared" button that already covers that state — and every
other state (staged-only queue, empty queue, etc.) — so both buttons hit
the same /clear-plate endpoint with identical optimistic-update semantics.
Two controls, one action, visible together in one specific state.
Remove the widget's button and its entire needsClearPlate render branch.
The widget becomes a passive "Next in queue" preview linking to /queue;
the card-level button remains the single plate-clear entry point.
Also drop:
- now-dead awaitingPlateClear / requirePlateClear / printerState props
from PrinterQueueWidgetProps and the matching call site
- orphaned queue.clearPlate / queue.plateReady translations from all eight
locale files (queue.clearPlateSuccess stays — used by the card button's
success toast)
- PrinterQueueWidgetClearPlate.test.tsx (654 lines) — every test asserted
the behaviour of the now-gone button; PrinterQueueWidget.test.tsx still
covers the passive-link path
Deliberately *not* changed: plate-status pill stays inside the Status box
(lines 2664/2671/2736/2783 of PrintersPage.tsx). Compact-view (Size S)
pill and icon-only clear button at :2664/:2671/:2673 untouched.
_watchdog_print_start reverted queue items to "pending" at 45 s if
gcode_state hadn't changed, assuming the MQTT project_file was swallowed
by a half-broken session (#887/#967). H2D Pro firmware (01.01.00.00)
routinely keeps state=FINISH for 48-55 s after actually accepting the
command before transitioning to PREPARE. The watchdog reverted items
the printer had already started physically printing; the archive updated
normally via _active_prints, but the queue item was now "pending" again,
and the next scheduler tick after plate-clear re-dispatched the same
item as if it had never run. With one item left in the queue that looked
like a reprint of the just-finished job; with multiple items the
symptom was masked by item N+1 getting dispatched during the race.
Add a second "command landed" signal: subtask_id advancing past the
pre-dispatch value. Bambuddy already mints a unique submission_id per
project_file publish (#1042) and the printer echoes it back on the next
push_status as soon as it starts processing the command - well before
gcode_state transitions on slow-transition models. _start_print now
captures pre_subtask_id alongside pre_state and passes both to the
watchdog, which exits early on either a state change or a subtask_id
advance.
Raise default timeout 45 s → 90 s as belt-and-braces for printers that
neither flip state nor echo subtask_id inside the polling window.
Genuinely half-broken sessions (both signals unchanged across the full
90 s) still revert + force-reconnect exactly as before.
Transient subtask_id=None during reconnect is not mis-detected as a
change. pre_subtask_id=None falls back to state-only checking so the
fix is safe for printers that haven't reported a subtask_id yet.
New test_scheduler_watchdog.py pins the eight behaviours that matter:
pickup via state change; pickup via subtask_id change with state still
FINISH (the exact #1078 case); revert when neither signal changes;
default timeout is 90 s; pre_subtask_id=None state-only fallback;
current subtask_id=None not treated as change; printer disconnect
mid-watchdog leaves DB untouched; item that already moved on is not
clobbered.
PR #939 added the awaiting_plate_clear gate but stored it on
PrinterManager, not on PrinterState. printer_state_to_dict() — which
builds every WebSocket printer_status payload — never emitted the flag,
so the frontend's WS merge preserved the stale false value. The only
path that surfaced true was the 30s HTTP fallback poll, and incoming WS
ticks kept bumping React Query's dataUpdatedAt, pushing the refetch out
further on chatty printers.
Emit awaiting_plate_clear from printer_state_to_dict by reading
printer_manager.is_awaiting_plate_clear(printer_id) directly; returns
False when no id is passed. No frontend change needed — the existing WS
merge carries the flag end-to-end and the button now appears the instant
the printer transitions to FINISH.
Regression tests assert the WS dict always contains the key and surfaces
True when the manager has the flag set for that printer_id.
Affects every printer (A1/H2D/X1C) equally — transport-agnostic path.
Opening the sidebar's Change Password modal while on the Printers page
caused the "Search printers" input to render as a masked password field
and stay that way after closing the modal.
Root cause: the modal had three type=password inputs but no accompanying
username anchor, so password-manager extensions (1Password, Bitwarden,
browser built-ins) hunted the DOM for a matching text input and latched
onto the unlabelled Printers-page search bar.
- Layout.tsx: add hidden autocomplete=username anchor at the top of the
Change Password modal form. Also ensures saved new passwords are
correctly keyed to the logged-in user.
- PrintersPage.tsx: harden the search input with type=search,
name=printer-search, autoComplete=off, data-1p-ignore, data-lpignore
so heuristic autofill skips it regardless.
Bambu Cloud returns filament_id=null for user presets that only override
fields of a generic base (e.g. "Sting3D ABS" inheriting from
"Generic ABS @BBL H2D"). ConfigureAmsSlotModal fell back to
convertToTrayInfoIdx(base_id), which strips "S" and the version suffix
from "GFSB99_07" to "GFB99" — Generic ABS's filament_id. The printer
accepted and echoed back GFB99, so OrcaSlicer / BambuStudio Sync
Filaments resolved the slot to "Generic ABS" and the custom preset
never appeared on the printer LCD.
The preceding default already set tray_info_idx to the PFUS*/PFSP*
setting_id unchanged, and the rest of the stack round-trips that
format (configure_ams_slot, inventory Assign Spool, and print
scheduler slot-matching on P* short-form IDs). The base_id branch
overwrote the correct default.
Remove the base_id fallback. When cloud detail returns a distinct
filament_id we still prefer it; otherwise the setting_id default
stands. BambuStudio Sync now resolves the custom preset cleanly.
OrcaSlicer falls back to the inherited generic because OrcaSlicer
user-preset JSONs don't carry a filament_id field — that is an
OrcaSlicer limitation and behaviour is strictly not worse than before.
Regression tests (frontend):
- filament_id=null keeps PFUS* as tray_info_idx
- concrete filament_id wins over the default
- GFS* path skips the cloud-detail fetch entirely
- fetch failure degrades gracefully to the PFUS* default
Regression tests (backend):
- test_configure_pfus_preserves_setting_id_pair: HT slot endpoint
forwards both tray_info_idx=PFUS… and setting_id=PFUS… untouched
Thanks to @mrnoisytiger for the browser-console / network / backend-log
data that isolated the fallback path and the OrcaSlicer preset JSON
that showed the missing filament_id field.
A single legacy spool with a 7-char rgba ('FFFFFFF', missing one F)
caused GET /api/v1/inventory/spools to 500 with a pydantic
ResponseValidationError, leaving the reporter with a blank Filaments
page and "Add Spool" silently failing. Root cause spans three layers:
1. Write path: SpoolUpdate.rgba had no pattern constraint (only
SpoolCreate did), so PATCH could plant malformed values in the DB.
2. Frontend: ColorSection hex input's `val.length <= 6 ? 'FF' : ''`
emitted 7-char rgba for 5-char input (XXXXX + FF = 7) and for
7-char typed input (no alpha appended).
3. Read path: SpoolResponse inherited the write-side pattern, so a
single bad row 500'd the entire list endpoint instead of being
tolerated through serialize.
SpoolUpdate.rgba now carries the same ^[0-9A-Fa-f]{8}$ pattern as
SpoolCreate. The hex input emits a fully-formed 8-char RRGGBBAA on
every keystroke — 8-char paste passes through, 7-char drops the
stray, shorter input pads RGB with '0' and appends FF alpha.
SpoolResponse.rgba is now Optional[str] with no pattern — write-side
validation is the right place for format rules; responses must
tolerate historical rows.
Tests: 16 schema tests (SpoolCreate/Update reject, SpoolResponse
tolerate), 7 frontend tests covering every input length 0–8 plus
non-hex strip. A user who already has a bad row in their DB now sees
it render with a default color instead of having to hand-edit SQLite.
The "Print" button on a printer card (and drag-drop-onto-card) used
FileUploadModal to persist the file as a LibraryFile, then dispatched
through POST /library/files/{id}/print. The LibraryFile row + disk file
were left behind after every one-off print, polluting File Manager with
entries the user never asked to save.
FilePrintRequest.cleanup_library_after_dispatch (default False) opts
into post-dispatch cleanup. When set, _run_print_library_file stages
db.delete(lib_file) in the same transaction as archive_print so a
mid-flight FTP / start_print failure rolls both back cleanly, commits
together, then unlinks the library disk file + thumbnail after commit
succeeds. External library files (is_external=True) are never touched.
Only the Printers-page Direct-Print PrintModal sets the flag. Every
other api.printLibraryFile caller (File Manager Print, Project Detail
Print) leaves it unset — their entries are there by user intent.
Also moves formatPrintName out of PrintersPage.tsx into a new
utils/printName.ts module — fa1c46d9 (#881) exported it inline so its
test could import it, tripping react-refresh/only-export-components.
The 0.2.3.1 fix (f03d0c4c) added current_user to the library print
endpoint and plumbed it into the dispatch job object, but the job
runner never read it back out. _run_print_library_file called
ArchiveService.archive_print() without created_by_id and never called
set_current_print_user, so archives created by the printer-card "Print"
button, File Manager prints, and Library prints all landed with
created_by_id=NULL and were invisible to the per-user statistics filter.
The post-print user-targeted notification also had no recipient.
Forward job.requested_by_user_id to archive_print() at creation time
and register the current-print user after start_print succeeds,
matching _run_reprint_archive (lines 686-691).
Reprint-from-Archive still shows NULL for archives whose original
created_by_id was NULL — the reprint path reuses the source row as-is
and only refreshes started_at. Tracked as a separate follow-up.
When two printers were running different plates of the same multi-plate
3MF, the Printers page cards displayed the same file name on both and
there was no way to tell them apart. The Queue view already had this
information by cross-referencing the archive's plate list; the card
didn't have the linkage.
Expose `current_archive_id` (resolved by matching the MQTT `subtask_id`
against `PrintArchive.subtask_id` — the bridge introduced in #972 for
restart-resume) and `current_plate_id` (parsed from `gcode_file` by a
new shared `parse_plate_id` helper) on the status endpoint. The helper
is also called from the WebSocket push path so plate transitions
reflect within 100 ms instead of waiting 30 s for the next REST poll;
the archive id itself stays REST-only since it's stable for the life
of a print and shouldn't make the push path touch the DB.
The card fetches plate metadata via the same `api.getArchivePlates()`
call QueuePage uses — shared React Query cache keeps it cheap across
polls — and renders the actual plate name (or a "Plate N" fallback)
only when `is_multi_plate` is true. Single-plate prints stay clean.
Falls back to the previous `plate_N.gcode` regex path when there's no
archive linkage (e.g. prints started directly from the printer LCD).
Tests cover the plate-id extraction across Bambu Studio path shapes
(backend parse_plate_id, printer_state_to_dict wiring) and the label
override precedence in formatPrintName (frontend).
The strict CSP shipped in 0.2.3b4 / 0.2.3.1 whitelisted only `https:`
for `frame-src`, so the Filament tab's Spoolman iframe was blocked
on the typical self-host setup where Spoolman runs on plain HTTP on
a LAN. Reporter saw a blank Filament page with a brief Spoolman
flash on reload and a browser-console CSP violation pointing at
`http://<host>:7912/spool`.
Allow `http:` as well, matching the `connect-src 'self' ws: wss:`
pattern already used for WebSockets. `frame-ancestors 'none'` still
prevents Bambuddy itself from being framed cross-origin, which is
the protection that actually matters for clickjacking defense.
After configuring an AMS-HT slot with a custom cloud preset, the slot
card and Configure modal kept showing "Generic PLA" even though the
printer and slicer had the correct preset. The `/slot-presets` response
keyed HT entries at `ams_id * 4 + tray_id = 512`, but frontend lookups
used `ams_id` directly (128 on PrintersPage via getGlobalTrayId, 64 on
SpoolBuddy via a one-off formula). All three agreed for regular AMS, so
the mismatch only surfaced on HT — the saved preset never reached the
UI and the render fell through to `tray.tray_type`.
Backend now keys via a helper that mirrors frontend `getGlobalTrayId`.
SpoolBuddy's AMS page switches to the shared helper. Regression test
covers regular, HT, and external slot keys.
The bed-jog "not homed" warning modal was gated on a session-scoped
"warned" flag set only by the "Move anyway" button. Clicking "Auto
Home" sent the G28 and closed the modal but never set the flag, so the
next jog click in the same session re-prompted — even though the
printer was now homed.
The homeAxes mutation's onSuccess handler now flips the same
`bambuddy.bedJog.warned.<printerId>` sessionStorage flag. The warning
still fires once per printer per session (intended safety guard,
cleared on restart), but not repeatedly after a successful auto-home.
(cherry picked from commit 1de4e409b0)
Critical safety fix. The bed-jog dialog's "Home Z" button sent a bare
`G28 Z` over gcode_line. On Bambu printers where the Z endstop is at
the top (bed moves UP into it — H2C, H2D, H2S, X1 family), `G28 Z`
skips the toolhead-park step that a full `G28` runs first, so the bed
rises at full speed with nothing getting out of the way. The reporter
only escaped damage because the toolhead happened to be parked on the
purge chute.
The /printers/{id}/home-axes endpoint and BambuClient.home_axes() now
always send bare `G28` regardless of the axes argument, triggering the
firmware's safe multi-step routine (park toolhead → home XY → home Z).
The axes argument is kept for API compat but ignored; invalid values
still return 400.
Frontend retitles the button "Auto Home" and updates the dialog copy
in all 7 locales so users aren't surprised when X/Y motion happens
before Z. Parameterized regression test asserts z/xy/all all produce
bare G28.
(cherry picked from commit 7026a6de77)
The bed-jog "not homed" warning modal was gated on a session-scoped
"warned" flag set only by the "Move anyway" button. Clicking "Auto
Home" sent the G28 and closed the modal but never set the flag, so the
next jog click in the same session re-prompted — even though the
printer was now homed.
The homeAxes mutation's onSuccess handler now flips the same
`bambuddy.bedJog.warned.<printerId>` sessionStorage flag. The warning
still fires once per printer per session (intended safety guard,
cleared on restart), but not repeatedly after a successful auto-home.
Critical safety fix. The bed-jog dialog's "Home Z" button sent a bare
`G28 Z` over gcode_line. On Bambu printers where the Z endstop is at
the top (bed moves UP into it — H2C, H2D, H2S, X1 family), `G28 Z`
skips the toolhead-park step that a full `G28` runs first, so the bed
rises at full speed with nothing getting out of the way. The reporter
only escaped damage because the toolhead happened to be parked on the
purge chute.
The /printers/{id}/home-axes endpoint and BambuClient.home_axes() now
always send bare `G28` regardless of the axes argument, triggering the
firmware's safe multi-step routine (park toolhead → home XY → home Z).
The axes argument is kept for API compat but ignored; invalid values
still return 400.
Frontend retitles the button "Auto Home" and updates the dialog copy
in all 7 locales so users aren't surprised when X/Y motion happens
before Z. Parameterized regression test asserts z/xy/all all produce
bare G28.
Three related fixes reported together:
(1) After resetting an AMS slot, the printer card showed "Empty Slot"
with no Configure or Assign Spool actions while SpoolBuddy's AMS page
still let the user re-configure the same slot. Commit c9efa4b8 (#784)
added a `tray?.state === 10` gate to the EmptySlotHoverCard actions,
intended to hide them on physically-empty slots (state=9). In practice
firmware often reports state=9 (or omits state entirely) after a
user-initiated reset even when a spool is still present, so the gate
hit the wrong case. The gate was redundant anyway — EmptySlotHoverCard
only renders when tray_type is empty — so it's removed at both the
standard-AMS and AMS-HT render paths.
(2) After configuring a slot with a Generic profile, the Assign Spool
modal hid manually-added inventory spools even when material matched,
unless the user flipped "Show all spools". The filter required exact
slicer_filament_name equality, which manually-added spools don't
populate. Filter now prefers exact slicer-profile match when both
sides have one, and falls back to partial material match in either
direction (so a "PLA" spool shows up for a "PLA Basic" slot).
(3) On assign, the mismatch dialog fired on every Generic spool
because Bambu Studio / OrcaSlicer profile names carry an @printer
nozzle (variant) qualifier while the tray stores the bare base name.
Both the filter and checkProfileMatch now strip everything from @
onward before comparing.
Adds 3 regression tests covering each path.
The parity gate expansion in 8f9eb0d4 started printing the full
missing-key and placeholder-mismatch lists for every informational
locale on every test run, which was noisy given CI only cares about
strict locales. Collapse info reports to one line per category
(`fr: missing keys vs en: 74`) and keep the full lists available via
VERBOSE_INFO=1 for when someone is actually catching up a locale.
The mini thumbnail wrapped its src with withStreamToken() (appends the
short-lived camera-stream token, needed because <img> can't send an
Authorization header), but the enlarged lightbox <img> used a bare
${status.cover_url}?view=top. On auth-enabled instances the backend
rejected the unauthenticated request and the browser showed the
broken-image icon. Wrap the enlarged src with withStreamToken() too.
maziggy