slice_and_persist writes a .gcode.3mf ZIP container but persisted the row
with file_type="gcode". The G-code preview endpoint short-circuits on
file_type == "gcode" and returns the bytes as text/plain, so the embedded
viewer received the raw ZIP body instead of the embedded toolpath.
- Persist file_type="gcode.3mf" on sliced rows (matches _classify_file_type
and external-scan rows).
- get_gcode also routes to the unzip branch when the filename ends with
.gcode.3mf, so rows already written under the bug self-heal on first
preview without a DB migration.
- Extend FileManagerPage badge + viewer-eye gate and ProjectDetailPage badge
to accept "gcode.3mf"; isSlicedFilename / isSliceableFilename already do.
- Add test_library_get_gcode_recovers_legacy_gcode_type_for_3mf: legacy
row preview must be text/plain, contain G28, and NOT start with PK.
Bundle import never delivered what it implied: BambuStudio's .bbscfg export
strips system processes/filaments, so importing a bundle left users without
process presets and slicing fell back to embedded settings on STL. Bundle
mode also hid the standard tier behind a constrained dropdown, the actual
trap reported here.
Removed end-to-end:
- backend: POST/GET/DELETE /slicer/bundles*, SliceRequest.bundle,
SliceBundleSpec, dispatch fork in library.py, bundle-context params on
the filament-requirements endpoints, bundle-fingerprint cache key in
slice_preview.py, SlicerApiService.{import,list,get,delete}_bundle and
slice_with_bundle, BundleSummary / BundleNotFoundError.
- frontend: BundlePicker + BundleStringDropdown, isBundleMode + every
branch, bundle state/queries/dispatch in SliceModal.tsx, SlicerBundle /
SliceBundleSpec types, three bundle API methods. buildCompatibilityIndex
loses its bundle path; presetCompatibility keeps compatible_printers
plus the @BBL fallback.
- SlicerBundlesPanel turns into a permanent static notice explaining the
removal, alternative import paths, and the new slice-time lookup order
(Imported > Orca Cloud > Bambu Cloud > Standard sidecar fallback).
- i18n: slicerBundlesRemoved.{title,description,alternatives,lookupOrder}
translated across all 11 locales; slice.bundle*, slicerBundles.* keys
removed.
Fixed (surfaced by removing bundle mode):
- _resolve_cloud and _resolve_orca_cloud now force type per slot and pin
from: "system" on the payload before json.dumps. Bambu Cloud ships
type as "printer"/"print" and routinely empty `from`; the BS CLI's
--load-settings parser rejects both with return -5 / "input preset
file invalid". Standard tier already did this; cloud paths now match.
Round 2 fixed the model-mode FilamentOverride: tray_info_idx →
sub-brand, plus a material-disambiguated colour name from a new
/inventory/colors/by-material endpoint. The printer-mode panel that
renders the same 3MF (FilamentMapping) was reading the same raw
fields — item.type for the required label, getColorName(item.color)
for the swatch tooltip — and was not touched, so picking "Specific
Printer" still showed "Required: PLA - Black" for a slice the
"Any H2D" branch already labelled "Bambu PLA Matte - Charcoal".
Extract the three-query resolution machinery from FilamentOverride
into a shared hook useFilamentLabels (returns positional
{resolvedName, colorLabel} per slot). Both panels call it; both
read the same labels. The hook also owns extractMaterialHint so the
"strip leading brand token" rule has one source of truth.
FilamentMapping required-side now reads {resolvedName} instead of
{item.type}; swatch tooltip reads `Required: {resolvedName} -
{colorLabel}` instead of `Required: {item.type} -
getColorName(item.color)`.
The Print Queue's schedule dialog hid the per-slot "Force color match"
checkbox when a specific printer was picked, even though the scheduler
in print_scheduler.py:535 honours force_color_match regardless of how
the queue item was created. Model-mode ("Any A1") rendered
FilamentOverride which carries the checkbox; printer-mode rendered
FilamentMapping which had no force-match UI at all. Pure UI gap.
Extend FilamentMapping to accept optional forceColorMatch +
onForceColorMatchChange props, mirroring FilamentOverride's signature,
and render the same <Palette>-iconed checkbox under each filament row
when a handler is wired. PrintModal/index.tsx passes the existing
forceColorMatch state through — same object both modes write into so
toggling between modes preserves the user's selection. No new i18n
keys (printModal.forceColorMatch already ships in all 11 locales).
Four #1712 issues from the 2026-06-04 Orca Cloud integration:
(1) Tier order put Orca Cloud above everything across SliceModal,
auto-pick scoring, dropdown groups, the AMS slot picker, and the
backend precedence. Bambu-Cloud-only users saw their profiles
deprioritised behind an empty Orca tier.
(2) Cross-tier dedup hid a same-named preset in all but the highest-
priority tier. A user with both a local-imported and an Orca-synced
"Bambu PLA Basic" couldn't see the Orca copy as a picker option.
(3) CloudStatusBanner nagged signed-out users with a permanent
"Sign in to Orca Cloud" line at the top of every slice -- even after
explicit logout. Bambu Cloud had the symmetric problem.
(4) ConfigureAmsSlotModal source badges were inconsistent: Orca rows
showed only "Custom" (no source identity), Bambu Cloud built-in rows
had no badge at all, and the orthogonal isUser-driven "Custom" badge
collided with the source badge for cloud user presets.
Order is local > orca_cloud > cloud > standard everywhere it lives
(SliceModal SLICE_MODAL_TIER_ORDER + TIER_BONUS + dropdown tier list,
ConfigureAmsSlotModal sourceOrder, and backend precedence). The order
drives auto-pick + visual group rendering; it does NOT hide profiles.
_dedupe_by_name replaced with _enrich_cloud_metadata: every tier
returns its full list across all three slots (printer / process /
filament). The function still backfills Bambu Cloud filament metadata
from same-named local / orca_cloud / standard entries so cloud
filaments score in pickFilamentForSlot.
CloudStatusBanner silently no-ops on not_authenticated for both clouds;
expired / unreachable still surface. The not_authenticated i18n keys
stay in the locale files dormant.
ConfigureAmsSlotModal: one source badge per row, one colour per source
(green Local / purple Orca Cloud / bambu-blue Bambu Cloud / amber
Built-in). The legacy isUser-driven "Custom" badge is gone; every row
identifies its tier consistently.
Drop the off-white background on the A2L marketing render so it composites
cleanly on the dark theme (every other printer image in public/img/printers/
is RGBA with transparent corners; A2L shipped as opaque #F7F7F7). Resize to
320x320 to match the rest of the artwork.
Also wire A2L into getPrinterImage so the printer card actually shows the new
artwork -- without this the resolver fell through to default.png for both
the A2L display name and the N9 internal SSDP code.
- frontend/public/img/printers/a2l.png: new, 320x320 RGBA, transparent
- frontend/src/utils/printer.ts: A2L / N9 -> a2l.png, placed above the a1mini
branch
- frontend/src/__tests__/utils/printer.test.ts: 4 cases mirroring the X2D
shape -- display name, case-insensitive variants, N9 internal code,
regression guard against accidentally matching A2M / A1 / A1 Mini
Internal code N9 (from BambuStudio resources/profiles/BBL/machine/Bambu Lab A2L.json),
serial prefix 26A19 (5-char, same shape as H2C's late 31B8B). Capabilities from
Bambu's official A2L specs page: linear rail, single FDM extruder + integrated
cutter/plotter, no Ethernet (2.4 GHz Wi-Fi only), low-rate chamber camera on
port 6000.
The BambuStudio profile's use_double_extruder_default_texture: true flag
describes two TOOL HEADS (FDM + cutter), not dual filament extrusion — A2L
must NOT be classified as dual-nozzle or AMS routing will target the deputy
slot and firmware rejects with 07FF_8012.
Registry updates: printer_models.py, firmware_check.py, virtual_printer/manager.py,
virtual_printer/mqtt_server.py, PrintersPage.tsx, SpoolBuddyAmsPage.tsx.
12 new test cases in TestA2LModel pin every dimension.
The Stats page's Failure Analysis widget and the per-archive run
sub-table rendered the raw PrintLogEntry.failure_reason value
without translating, so the camelCase keys saved by the new
Print Log row editor (#1687 part 4) surfaced as literal
"filamentRunout" / "cloggedNozzle" text. The Print Log table did
translate the value, so the inconsistency was visible from one
surface to the next.
EditArchiveModal was also still saving the localised label as the
column value while the new editor saved the key - same column,
two formats, two failure modes (group fragmentation on language
switch, new PATCH validation rejection on round-trip).
Three surfaces fixed in one drop:
1. StatsPage.tsx and PrintLogTable.tsx wrap the value in
t('editArchive.failureReasons.${reason}', { defaultValue: reason }) -
the defaultValue path keeps legacy translated-text rows rendering
unchanged.
2. EditArchiveModal stores the camelCase key on save and reverse-
looks up any legacy translated-text value against the current
locale on open. Every save thereafter converts that row forward
to the key format, so the column self-heals over time.
3. Added htmlFor/id to the failure-reason label/select pair (a11y
plus testability).
Configure Slot dropped to "default 0.020" on reopen for slots that were
physically loaded but unconfigured (tray_type="", no slot_preset_mappings
row). The #1689 cali_idx safety net was unreachable from that path —
matchingKProfiles early-returned [] on !selectedPresetInfo before the
safety net ran.
Split the early return so the cali_idx fallback survives the no-preset
case: when selectedPresetInfo is null but slotInfo.caliIdx > 0, return
the active profile as a single-item list (extruder-matched when known).
Strictly additive; caliIdx == 0/null still returns [], existing matcher
unchanged when a preset is resolvable.
Two complementary surfaces for the most-missed install step ("Store sent
files on external storage"):
1. Connection diagnostic check (printer-side variant)
- Reads state.store_to_sdcard, parsed from MQTT home_flag bit 11.
- Pass / fail / skip; instant, no I/O.
- Catches the newer-firmware variant where the toggle moved onto the
printer itself (P2S 01.02 / Studio 2.6+).
An FTP upload-and-verify probe was tried first and rejected. /cache
is always writable from Bambuddy regardless of the slicer setting;
only BambuStudio's own behaviour changes when the toggle flips.
Empirically confirmed against X1C + H2D with the slicer option
toggled off: probe still succeeded, home_flag bit 11 stayed True.
2. Archives-page banner (slicer-side variant)
- The slicer-side toggle is invisible to the printer — older
BambuStudio doesn't push the change to the printer. The diagnostic
can't see it.
- Symptom is deterministic: archiver creates rows with
extra_data.no_3mf_available=True (main.py:2770) when it can't pull
the 3MF from /cache after a slicer-initiated print.
- New endpoint GET /archives/no-3mf-warning returns whether any
archive in the last 30 days has the flag (excluding soft-deleted).
- Amber dismissible banner at the top of /archives; one-shot
localStorage dismissal (matches Layout.tsx update-banner pattern,
but persistent across sessions).
- React-Query disabled after dismissal so the endpoint isn't polled
once the user has been told.
Detects the printer-side variant of install step 4 — many users (esp. on
clean installs) forget to enable this and only notice when their archive
cards have no thumbnails. The diagnostic now catches it upfront.
Detection: read state.store_to_sdcard, which Bambuddy already parses from
MQTT push_status home_flag bit 11 (bambu_mqtt.py:153). Instant, no I/O.
An FTP upload-and-verify probe was tried first and rejected. /cache is
always writable from Bambuddy regardless of the slicer setting — only
BambuStudio's own behaviour changes when the toggle flips, not the
printer's acceptance policy. Confirmed empirically against X1C + H2D
with the slicer option toggled off: probe succeeded, home_flag bit 11
stayed True. So the only reliable signal is what the printer actually
reports about its own state.
Limitation: the printer-side variant only exists on newer firmware
(P2S 01.02 / Bambu Studio 2.6+). On older versions the toggle lives
only in the slicer and the printer never hears about it, so this check
will pass even when the user is missing step 4 in BambuStudio. The
skip-text and the wiki call this out explicitly. A reactive banner on
the no-3MF archive-fallback path is planned as a follow-up to cover
that case.
Statuses:
- pass: state.store_to_sdcard is True
- fail: state.store_to_sdcard is False (-> overall escalates to problems)
- skip: no live state, disconnected, or field never populated
(#1687 part 4, reported by @IndividualGhost1905)
Reporter clarified after part 1 shipped that point 2 wasn't about
archive `tags` (which describe the model — home decor, toys), but
about failure-cause classification on the *log* row itself:
spaghetti, jam, bed-adhesion, etc. Different surface, different
lifetime.
The data field he wanted already existed. PrintLogEntry.failure_reason
is a String(100); the Failure Analysis widget already groups by it;
the Archive Edit modal already mirrors archive.failure_reason into
the most recent log entry (archives.py:1421, shipped with #1444).
The only gaps were:
1. The GET endpoint silently dropped failure_reason (and archive_id
and created_by_id) from PrintLogEntrySchema construction even
when set in the DB — so the Print Log table couldn't render what
the Failure Analysis widget grouped by. Fixed independently of
the editor; regression test added.
2. Orphan log entries (no archive — dispatch errors, aborts before
archive creation, manual entries) had no edit path at all because
the Archive Edit modal cannot reach them. The new endpoint is
the only way to classify those rows.
Changes:
- Backend: new PATCH /print-log/{entry_id} taking
{failure_reason, status}, gated on require_ownership_permission(
ARCHIVES_UPDATE_ALL, ARCHIVES_UPDATE_OWN) — same ownership shape
as the per-row DELETE. Validates against the same 11-key failure
vocabulary and 5-key status set the Archive Edit modal uses;
unknown values return 400 rather than getting stored as raw text
(the i18n layer maps the value back through the vocabulary,
unrecognised values would render as literal strings).
Empty-string failure_reason stores back as NULL so the column's
nullable=True intent is preserved end-to-end. GET endpoint now
surfaces failure_reason, archive_id, created_by_id.
- Frontend: FAILURE_REASON_KEYS moved to an export from
EditArchiveModal.tsx so the new editor reuses the exact same
vocabulary — backend and frontend stay in lockstep. Pencil icon
beside the existing trash icon on every Print Log row, opens a
compact two-field modal (status + failure reason). Save
invalidates print-log and archives-stats query keys so the
Failure Analysis widget reflects the re-classification on the
same response cycle. Failure reason rendered as a sub-label under
the status badge, matching PrintLogTable.tsx's convention.
- i18n: 10 new keys (editEntryTitle, editEntryDescription,
entryUpdated, entryUpdateFailed, archives.permission.noEdit, plus
a 5-key statuses block) translated across all 11 locales. No
English fallbacks.
- Wiki: features/print-log.md gains per-row actions section,
updated permissions table, PATCH/single-DELETE endpoint docs.
When the user clicked Print Anyway on a filament-deficit warning, the
acknowledgement was one-shot. The route cleared manual_start and
filament_short, then the next scheduler tick re-ran
compute_deficit_for_queue_item against identical spool state, found
the same deficit, and re-set both flags. The item bounced between
"user said anyway" and "scheduler re-blocked" — every Play click
returned 409, every confirm got rolled back on the next tick.
Add a persistent acknowledgement flag on the queue item:
- New column `skip_filament_check` on print_queue. SQLite + Postgres
migration branched on is_sqlite() so Postgres doesn't reject
DEFAULT 0 on BOOLEAN.
- PrintQueueItemCreate + PrintQueueItemResponse schemas + the
TypeScript types carry the field.
- POST /print-queue/{id}/start with skip_filament_check=true now
ALSO sets item.skip_filament_check = True (not just clearing
manual_start / filament_short).
- PrintScheduler._block_on_filament_deficit short-circuits to
False — no compute, no flag-setting, no notification — when
item.skip_filament_check is True. We trust the operator's
decision and stop fighting them.
- PrintModal at queue-creation time threads
skip_filament_check=true into the create payload when the user
clicks Print Anyway on the frontend deficit warning, so a print
that was warned-then-acknowledged at add-to-queue time goes in
pre-acknowledged — scheduler never blocks it on first tick.
Flag is not auto-cleared on spool swap by design: if remaining is
now sufficient, the check returns no deficit anyway, so the flag
is moot. Auto-clearing would add lifecycle complexity without
changing behaviour.
AMS Backup awareness (the other half of the discussion) intentionally
NOT included — verified the H2D's bit-26 of print.cfg toggles with
the printer-side AMS Backup setting, but the X1C's cfg has a
different shape entirely and verifying every model family isn't
realistic. Silently under-warning would be worse than always
per-slot. The check stays single-slot for now.
Two related bugs in K-profile matching, same root cause.
#1688 — spool form's PA-profile suggester (PAProfileSection via
isMatchingCalibration in spool-form/utils.ts) matched K-profiles by
parsing the profile NAME for material/brand/variant. Spools already
store slicer_filament (the slicer preset id) and K-profiles already
carry filament_id, but both were ignored — so a user's custom
K-profile whose name doesn't agree with the slicer preset got silently
dropped from suggestions even when the underlying filament_id was
identical.
#1689 — ConfigureAmsSlotModal's matchingKProfiles ran the same
name-only logic on the slot's selected preset. A spool assigned under
"Generic PLA" with a custom K-profile actively bound on the printer
landed in the modal as "K profile not assigned, default 0.020 will
be used", while the printer-card hover-card correctly showed the
active profile. Two paths, only one was filtering by name.
Shared root: spool preset ids and K-profile filament_ids look
different but are equivalent after normalising. Spools store
slicer_filament as the cloud setting_id form ("GFSG98_09" — _09 is
the variant suffix, the S infix marks setting_id form); K-profiles
store filament_id as the bare form ("GFG98"). Plain === doesn't
work; both need normalising. This conversion already existed in the
other direction at buildFilamentOptions (filament_id → "GFS" +
filament_id.slice(2)), so the inverse toFilamentId helper is just
the matching reverse, not new ground.
Fix — one shared helper, two surfaces:
- spool-form/utils.ts: new exports toFilamentId(id) (drops "_NN"
variant suffix and strips the "S" in "GFS", so GFSG98_09 → GFG98)
and isGenericFilamentId(id) (flags Bambu's generic GFx99 ids
which are shared across many filaments and must NOT id-match —
the name fallback handles those correctly).
- isMatchingCalibration: gains slicer_filament?: string in formData,
tries id-match (with generic exclusion) before the existing name
parse. PAProfileSection already passes the full formData so no
caller edit needed. Strictly additive precedence.
- ConfigureAmsSlotModal.selectedPresetInfo: resolves a filamentId
field (toFilamentId(cp.setting_id) for cloud presets,
toFilamentId(builtinFilamentId) for builtin; empty for local /
orca paths which fall through to name match).
- ConfigureAmsSlotModal.matchingKProfiles: id-match check at the top
of the per-profile predicate (preferred when both sides agree
after normalisation), then the existing name-parse logic, then
ALWAYS unshifts the slot's currently-active K-profile by
slot_id === slotInfo.caliIdx — gated on activeIdx > 0 (so caliIdx
0/null doesn't leak unrelated profiles in), extruder-matched when
slotInfo.extruderId is known. This is Spionkiller01's #1689 patch
verbatim with the activeIdx > 0 guard added.
SpoolBuddy: both kiosk K-profile surfaces reuse the shared
components. SpoolBuddyWriteTagPage renders PAProfileSection;
SpoolBuddyAmsPage renders ConfigureAmsSlotModal. Verified — fixes
propagate automatically, no kiosk-specific edits.
What this does NOT change: spools without slicer_filament, K-profiles
without filament_id, and generic GFx99 ids all fall through to the
existing name-based matching path. Strictly additive precedence; no
input shape that matched under the old logic fails to match under the
new. The #1053 cloud-preset PFUS* path is preserved because the
toFilamentId regex /^GFS/ doesn't match a "PFU" prefix.
When the JWT expired on an open tab, the next API request hit a 401 with
"Token has expired"; client.ts cleared the token from storage but
AuthContext.user stayed populated from the original mount. ProtectedRoute
only redirects when user === null, so the protected tree kept rendering
and every subsequent request silently failed with no Authorization
header — the UI looked like every list was empty until a manual refresh
remounted AuthProvider.
The 3 other setAuthToken(null) sites live inside AuthContext itself and
already pair with setUser(null), so only the client.ts cross-module
site needed a React-tree signal.
- client.ts: after setAuthToken(null) on a token-invalidating 401,
window.dispatchEvent(new CustomEvent('auth:expired')). Guarded on
`typeof window !== 'undefined'` for SSR / test safety. Generic
"Authentication required" 401s still don't clear the token or fire
the event — treated as transient timing issues per the pre-existing
comment at client.ts:155.
- AuthContext.tsx: mount useEffect adds a window listener that calls
setUser(null) under the mountedRef guard; cleanup removes the
listener so unmount → remount doesn't double-bind.
Mirrors the patch the reporter shipped on their fork (deec96d1).
Reporter on a 3-AMS P1S saw slots labelled "Empty" even though spools
were physically loaded - OrcaSlicer's Device view showed the same
slots as loaded.
Root cause: the compact label below the AMS slot circle rendered
tray.tray_type || t('ams.slotEmpty'), falling back to "Empty" whenever
the printer firmware hadn't been told which material is in the slot.
getEmptySlotKind already distinguishes 'physical' (firmware confirmed
empty via state 9/10) from 'reset' (tray_type absent but firmware
hasn't confirmed empty - spool loaded, just unassigned). The hover
card and circle border already used that distinction; the compact
label did not.
Fix: label branches on emptyKind - 'physical' keeps "Empty", 'reset'
shows "?" matching the slicer's own convention. External / VT tray
label is unchanged (external trays have no "configured/unconfigured"
distinction - they're either loaded or not). SpoolBuddy AmsUnitCard
carried the same bug and got the same fix plus a tooltip.
Reporter noted the existing "Also remove this print from Quick Stats"
toggle at archive delete is one-shot: if you kept stats then, there was
no later way to drop the row; and rows without a backing archive
(errors, aborts, manual entries) had no delete affordance at all.
Backend: DELETE /print-log/{entry_id} mirrors delete_archive's
ownership flow via require_ownership_permission(ARCHIVES_DELETE_ALL,
ARCHIVES_DELETE_OWN). Owners drop their own rows; admins drop any row;
missing IDs return 404 rather than 200-silently. /archives/stats
aggregates over PrintLogEntry, so the filament / time / cost / count
contribution drops out of Quick Stats in the same response cycle. The
linked archive (if any) is untouched - the log row is a sibling, not a
child.
Frontend: trash icon next to the filament cell on every row, gated on
the same permission shape as the archive trash. Confirm modal -> row
gone. Mutation invalidates both print-log and archives-stats query
keys so the totals re-render without a manual refresh.
#1687 also asks for per-row tagging (already covered by
EditArchiveModal's tags field) and per-row filament-usage-history
edits (deferred - "restore deducted grams" is only consistent for the
most recent usage row per spool; needs a separate design call).
Reporter wanted to slice via the Bambu Studio sidecar but open files
locally in OrcaSlicer. preferred_slicer drove both the in-app
SliceModal sidecar selection AND the desktop "Open in Slicer" URI
handoff, so picking one forced the other.
New open_in_slicer setting (str | None) drives only the desktop URI;
null inherits from preferred_slicer so existing installs behave
identically. Storage in the existing app_settings key/value table;
GET normalises the "None" string back to null mirroring the
default_printer_id convention.
Frontend: Settings -> Slicer card adds a second dropdown ("Open in
Slicer" with "Same as API slicer" / Bambu Studio / OrcaSlicer);
ArchivesPage, MakerworldPage, ModelViewerModal switch desktop-URI
call sites to open_in_slicer ?? preferred_slicer. MakerworldPage's
"Slice in {{slicer}}" label additionally branches on useSlicerApi
so the label matches what the button actually dispatches.
Reporter on a multi-printer farm with 40+-plate runs needed to walk to
the printer with the right physical plate, but the queue and the
scheduling modal didn't surface curr_bed_type the way the archive card
already did.
New utils/threemf_tools.extract_bed_type_from_3mf helper (per-plate) so
both the queue API and the /plates endpoint can return per-plate values.
PrintQueueItemResponse.bed_type populated from archive.bed_type /
library_file.file_metadata['bed_type'] as the default, then overridden
per-plate via the helper when item.plate_id is set. /archives/{id}/plates
(and library equivalent) include bed_type in each plate object.
Per-plate accuracy matters because archive.bed_type is captured at
ingest as only the first plate's value (services/archive.py:235) -
a 40-plate 3MF mixing PEI + Engineering returns PEI at the archive
level for every plate. The helper re-reads the 3MF and returns the
truth.
Frontend: queue card meta row + PlateSelector per-plate row + PrintModal
header all render bed icon + canonical label via the existing
getBedTypeInfo() helper, same as the archive card.
Bambuddy's project_file MQTT payload hardcoded "nozzle_offset_cali": 2 (skip),
giving users on H2D / H2D Pro / H2C / X2D no way to control the same toggle
BambuStudio exposes. Critical for diamond-nozzle setups that must keep the
calibration off.
start_print() now takes a nozzle_offset_cali kwarg; the value is encoded as
1 (run) or 2 (skip) and gated on is_dual_nozzle so single-nozzle machines
always send 2 even if a stale flag arrives. The kwarg threads through
printer_manager, both background_dispatch sites, and print_scheduler so
every dispatch path respects the per-item setting.
print_queue gains a nozzle_offset_cali column (DEFAULT TRUE, is_sqlite()
branch for Postgres BOOLEAN). Settings default key default_nozzle_offset_cali
defaults to TRUE to match BambuStudio. Schemas updated across print_queue,
library FilePrintRequest, archive ReprintRequest, settings.
PrintModal renders the new toggle only when the selected printer is dual-
nozzle (printer-mode: nozzle_count===2; model-mode: DUAL_NOZZLE_MODELS).
SettingsPage default-print-options row + QueuePage bulk-edit tri-state both
hide unless any registered printer is dual-nozzle. Labels reuse the existing
settings.default* keys so the only new i18n strings are
settings.defaultNozzleOffsetCali / Desc and queue.bulkEdit.nozzleOffsetCali
- real translations in all 11 locales.
Backend correctly defers MQTT configuration when the AMS slot is empty
at assign time (state ∈ {9, 10}) — firmware drops the push silently;
on_ams_change replays the config once a spool is detected. The
response carries pending_config=true to communicate that. The
printer-card AssignSpoolModal was ignoring the flag and always
showing "Spool assigned and AMS slot configured" — the SpoolBuddy
modal has handled this since it shipped. Now mirrors the same
branch and shows "Assigned. Slot will configure when you insert
the spool." when pending_config is true.
Repro on every fresh demo subdomain: visitor lands on Printers OK, first
sidebar click sticks on a spinner (Chromium) or trips "Corrupted Content
Error" with sw.js stuck `activating` (Firefox). Manual reload recovers.
Root cause is the `client.navigate(client.url)` call added to the activate
handler in 18d534c9 (intended to force kiosks to pick up new bundles).
Its guard — `client.url && typeof client.navigate === 'function'` — does
not distinguish first install from upgrade. On any fresh origin (every
demo session, every first-time visitor, every cleared profile) it still
fired: Chromium raced it against the in-flight SPA mount; Firefox
deadlocked the activate's waitUntil on `await client.navigate(...)`
because the SW intercepts its own document fetch while still activating.
Split the lifecycle correctly:
- sw.js activate handler: just cache cleanup + clients.claim().
- sw-register.js: capture `hadController = !!serviceWorker.controller`
at load, listen for `controllerchange`, reload only when hadController
was true. Returning kiosk hits a new deploy -> had controller -> reloads
as before; first-install visitor -> no controller -> no forced nav ->
React mount completes.
Bump CACHE_NAME v29->v30 and STATIC_CACHE v28->v29 so existing browsers
fetching the new sw.js drop the old CacheStorage in the same pass.
SpoolBuddy unregister branch and notificationclick's client.navigate are
unrelated and unchanged.
ThreeMFParser._parse_3dmodel left XML-escaped values raw, so a Title of
"PCB Vise & Solder Station" landed in the DB as the literal "&" and
React re-escaped it on render to "&amp;". Apply the same
loop-until-stable html.unescape() the sibling ProjectPageParser already
uses, uniformly across all <metadata> values.
Same drop: rewrite the VP archive-name-source tooltip in all 11 locales.
BambuStudio 2.7.x (PrintJob.cpp:314-325) overwrites the user-typed
Send-dialog name with the slugified 3MF Title field whenever one is
present, so the previous "handy if you renamed the job in the send dialog"
copy was false. New text spells out the actual behavior; both Filename
and Metadata modes often produce the same string for that reason.
100vh and window.innerHeight report the layout viewport on iOS Safari, so
the popover's Start Drying button rendered behind the bottom toolbar overlay.
Switch the popover maxHeight to 100dvh and default computePopoverPosition's
viewportHeight to visualViewport.height (with innerHeight fallback). The
flip-above decision and the body-scroll fallback now both run against the
actually-visible area, so the footer button stays reachable on iPhone.
Reporter on an A1 Mini saw the AMS slot Configure dropdown render no
Bambu / Generic filament profiles, and saw the Profiles tab strip
A1 Mini results when filtering by that model. Bambu rolled out a
profile rename mid-2026: the @BBL <code> suffix on 106 cloud profiles
shifted from the long display form to a terse model code -- e.g.
"Bambu PLA Basic @BBL A1 Mini ..." is now
"Bambu PLA Basic @BBL A1M ...". User-authored profiles still use the
long form. Bambuddy's filters did a verbatim uppercase compare
("A1M" vs "A1 MINI"), so every renamed cloud profile silently
disappeared from the picker.
Centralize the alias check in slicerPrinterMatch.ts. New
PRINTER_MODEL_SUFFIX_ALIASES table maps "A1 Mini" <-> "A1M"
bidirectionally; exported matchesPrinterModelSuffix() does the
case-insensitive compare with the alias fallback. Two consumer
sites swap to the helper:
* ConfigureAmsSlotModal.tsx (Orca cloud and Bambu cloud filter
branches) -- the AMS slot picker, hit directly and reached from
SpoolBuddy's AMS page via mapModelCode(printer?.model)
* slicerPrinterMatch.ts:classifyByBambuName -- the SliceModal
Process / Filament compatibility check
Backend printer_models.py also gets a "Bambu Lab A1M" -> "A1 Mini"
entry so server-side 3MF model normalization stays consistent if a
3MF ever embeds the short form.
Kept the alias table narrow on purpose. Wide-net aliasing (e.g.
"X1" <-> "X1C") would silently collapse physically distinct
printers. When Bambu introduces the next rename, it is one new row
in the table -- /api/v1/cloud/settings is the place to grep, called
out in the source comment.
Non-proxy VPs (Archive / Review / Queue) with a target printer set up
a live-mirror bridge that forwards the slicer's MQTT and RTSPS auth
bytes through to the real printer. The slicer holds one code in its
profile (the one it bound the VP with), and that code has to satisfy
both the VP listener and the real printer at the far end of the
bridge. If the codes diverge the bridge silently fails at the second
hop — slicer reaches .49:8883, FINs before sending a ClientHello,
retries identically. The wiki framed the code-match requirement as a
camera-only concern; it isn't, all bridged protocols inherit.
Fix removes the foot-gun instead of re-documenting it. When a target
is selected on a non-proxy VP the access-code field switches to a
read-only display showing the target's code with an Eye-toggle
reveal; the backend auto-inherits on every create / update (any
explicit access_code submitted alongside a target is silently
overridden as belt-and-braces for non-UI clients). The required-when-
enabling check now treats target-set as satisfying the access-code
requirement. Standalone (no-target) non-proxy VPs still get the
editable input + Save button.
One-shot startup migration corrects any pre-existing mismatched
rows: SELECTs diverged VPs and logs one INFO line per row for the
audit trail, then UPDATEs via correlated subquery. Idempotent and
portable between SQLite and Postgres.
Bambu's end-gcode lowers the bed at gcode_state=FINISH. Bambuddy's
live-camera grab captured the bed already dropped, ruining the photo
framing. Source the photo from a brief Bambu timelapse instead —
firmware stops timelapse recording AFTER toolhead parks but BEFORE
bed-drop runs, so the last frame frames the finished print correctly.
When capture_finish_photo is on AND the user did not opt in to
timelapse for this print, force timelapse=True at dispatch + mark the
new PrintArchive.bambuddy_forced_timelapse column. After extraction
(success or failure), cleanup deletes the locally-attached file,
clears archive.timelapse_path, and walks the four scanner directories
(/timelapse, /timelapse/video, /record, /recording) trying FTP DELE
against the original filename. User-opted-in timelapses pass through
unchanged.
Resolver lives at services/background_dispatch.py::resolve_effective_timelapse
(module-level so the print queue can reuse it). Both dispatch paths
wired: background_dispatch.py (Print Now / Reprint) AND
print_scheduler.py:_start_print (the queue). Field testing caught the
scheduler gap on the first round — AST regression test now asserts
start_print(timelapse=...) references effective_timelapse, not the raw
item.timelapse, so a future refactor can't silently drop it.
Extractor: ffmpeg -i input.mp4 -update 1 -q:v 2 out.jpg. Decoded
frames overwrite the same output file, so the file left on disk is the
literal last frame regardless of duration. Bambu records one frame per
layer-change, so a 16-layer cube produces a 0.6 s timelapse — the
original -sseof -1.0 approach seeked before the start of the file and
returned frame 0 (empty bed). Decoding every frame is fine; Bambu
timelapses are short by construction even on hours-long prints.
Migration adds bambuddy_forced_timelapse branched on is_sqlite()
(DEFAULT 0 / DEFAULT FALSE — PG rejects DEFAULT 0 for BOOLEAN).
Verified live on postgres:16-alpine.
Photo-task wait_for budget extends 45s -> 75s when timelapse_was_active
so the notification carries the bed-up photo instead of falling back
to the live-cam grab on slow links.
Scope limit, documented in the camera wiki: prints started directly
on the printer touchscreen / Bambu Handy / Bambu Studio Send bypass
both dispatch paths, so the override doesn't fire there. Future
option: mid-print M981 S1 P20000 MQTT toggle in on_print_start.
Setting description rewritten in all 11 locales to drop the "only
works when timelapse enabled" caveat (Bambuddy now forces it) and
explain the kept-or-deleted behaviour.
SSDP multicast (239.255.255.250:2021) doesn't traverse routers, so a
printer behind a router on a different L3 segment was invisible to
"Discover Printers on Network". Docker mode had a CIDR text input but
only as a fallback when zero interface subnets were detected; native
mode had no subnet field at all.
AddPrinterModal now surfaces an always-visible subnet picker. Detected
interface subnets stay as dropdown options, plus a "Custom subnet..."
sentinel reveals a CIDR text input. When custom is picked, discovery
routes through POST /discovery/scan with the typed CIDR instead of
SSDP (which would no-op against a foreign subnet anyway). Last custom
CIDR persisted to localStorage so VLAN users don't retype every time.
Scan button label and scanning / no-printers-found strings all key off
(isDocker || useCustomSubnet) so wording stays "Scan Subnet..." /
"Scanning subnet..." whether the user is on Docker or just picked
Custom.
Backend unchanged: SubnetScanner.scan_subnet() already accepts any
CIDR, already caps at /22 (1024 hosts), POST /discovery/scan already
takes user-supplied input.
Reporter on a 1508x831 Pi display couldn't mark a project as Completed
because the edit modal's height exceeded the viewport: the outer wrapper
centers vertically and the inner card had no max-h and no overflow, so
the top half scrolled above and the bottom half (Status dropdown +
Save/Cancel) scrolled below. Workaround was a full page reload.
Standard flex-modal-scroll fix: max-h-[calc(100vh-2rem)] + flex flex-col
on the card; a flex-1 overflow-y-auto min-h-0 wrapper around the form
fields; Cancel/Save moved into a flex-shrink-0 sibling with a border-t
separator so they're always visible regardless of scroll position.
Buttons stay inside <form> so type="submit" still works.
Reporter linked a NAS and the auto-imported files drowned their own
Bambuddy uploads in the "All Files" sidebar listing. There was no filter
to escape it — only per-folder clicks. Restore the pre-external semantics:
"All Files" now lists managed-storage files only. The combined
across-every-external view moves to a new sibling sidebar entry,
"External", that only appears when at least one external folder is linked.
Backend: GET /api/v1/library/files gains internal_only and external_only
query flags. Filter is on LibraryFile.is_external. Both flags set is a
400, not a silent pick-one.
Frontend: new topLevelView state on FileManagerPage (default internal);
the query passes the scope only when selectedFolderId is null. Mobile
selector dropdown uses __top:internal / __top:external sentinels so the
same state round-trips through option values. Empty-state copy
distinguishes internal-empty from external-empty.
The old endpoint name implied that calling it would drop weight_used to
0. In practice it only stamps weight_used_baseline = weight_used so the
Inventory page's "Total Consumed" widget (weight_used - baseline) reads
0 going forward, while remaining (label_weight - weight_used) is
preserved. Calling the endpoint via curl and seeing weight_used
unchanged in the JSON response is confusing.
New paths:
- internal: /api/v1/inventory/spools/{id}/reset-consumed-counter
/api/v1/inventory/spools/reset-consumed-counter-bulk
- spoolman: /api/v1/spoolman/inventory/spools/{id}/reset-consumed-counter
/api/v1/spoolman/inventory/spools/reset-consumed-counter-bulk
Behaviour is unchanged in both modes; internal stamps the baseline
directly, Spoolman-mode PATCHes upstream used_weight=0 and the
_map_spoolman_spool read mapping reconstructs the same "displayed
consumed = 0, remaining unchanged" Bambuddy-visible shape. Parity
between modes was already in place and is preserved.
The Spoolman-client method reset_spool_usage keeps its name because it
describes what is sent upstream to Spoolman, not what Bambuddy's
endpoint promises to callers.
Frontend:
- api.resetSpoolUsage / bulkResetSpoolUsage (and Spoolman variants)
renamed to resetSpoolConsumedCounter / bulkResetSpoolConsumedCounter.
- Button labels: "Reset usage to 0" -> "Reset counter" / "Reset all
counters" (short, unambiguous); tooltips and confirm-modal bodies
still spell out the full semantics.
window.open(url, '_blank', 'noopener,noreferrer') returns null even on
success per the WindowFeatures spec — `noopener` deliberately suppresses
the return reference. The label-print modal treated null as "popup
blocked → fall back to <a download> click", so the fallback fired on
every click. Result: window.open opened the blob tab (downloading a
random-named PDF on systems without an inline viewer) AND the fallback
downloaded bambuddy-labels.pdf — two identical PDFs per click.
Drop noopener,noreferrer. The blob is same-origin, the destination is a
passive PDF preview tab with no script context, and noreferrer is no-op
for blob URLs. window.open now returns a real window reference on
success and the if (!win) fallback only fires on genuine popup-block.
The existing connection diagnostic proved TCP + TLS + auth + SUBSCRIBE but
not that the printer was actually publishing reports. A wrong-cased serial
passes mqtt_auth because the broker accepts the subscription regardless;
the user-visible symptom is empty AMS / no K-profiles / no custom filaments
in the slicer Device tab because the VP cached state is empty. Bambuddy
already logged the actionable hint at bambu_mqtt.py:498 but only to
container logs.
New printer_publishing check turns that warning into a structured
diagnostic result. Pass = bridge has seen at least one report since the
last (re)connect; fail = zero reports across the wait window with fix-text
pointing at the case-sensitive serial. Bounded 10s poll on the on-demand
UI route, no wait on the support-package gathering path so bundling stays
fast. Exits the moment a message arrives — typical wall-clock is 1-2s.
Frontend renders an elapsed-seconds counter plus a "Listening for status
report — up to 10s" hint during the pending state so the wait doesn't look
hung. PUBLISH_WAIT_DEFAULT_SECONDS pinned on both sides.
report_messages_since_connect exposed as a public property on
BambuMQTTClient so the diagnostic doesn't reach into private state.
The Scheduled Local Backups time-of-day picker was interpreted as UTC by
_calculate_next_run, so a UTC+3 user had to enter 18:00 to get a 21:00
local backup. The UI labeled the field "UTC" but it was still surprising.
Picker is now interpreted in the container's local timezone, resolved
from the TZ env var via zoneinfo.ZoneInfo (same source the Support page's
environment.timezone shows). UTC fallback when TZ is unset or
unrecognised. The /local-backup/status endpoint exposes the resolved
zone, and the UI renders it next to the field via a new
backup.localTimeHint i18n key with real translations in all 10
non-English locales.
One-time behaviour change for users who entered a UTC time as a
workaround: the first scheduled cycle after upgrade will run at their
local TZ offset earlier than expected. Re-enter the time as local once
and it is correct from then on. No migration is shipped; migrating
around a DST boundary would be ambiguous.
ESLint no-useless-escape flagged 156 errors (153 in ko.ts, 3 in tr.ts):
\" inside single-quoted Korean strings and \' inside double-quoted
Turkish strings. The escapes weren't needed because the surrounding
quote style differs from the escaped quote. Visible-text unchanged;
i18n parity green at 5007 leaves × 10 locales.
Four frontend formatDate / formatDateTime helpers called new Date(iso)
directly on backend timestamps that have no timezone indicator. Per
ECMAScript, a bare "2026-06-02T07:50:00" is parsed as local time, so
a UTC-stored value got displayed as if its numeric components were
already local — visually identical to UTC. Same shape as the #504
fix from Feb 2026, which patched 13 sites but missed these four:
PrintLogTable and SpoolUsageHistory hadn't been written yet;
CameraTokensPage and SpoolBuddySettingsPage existed but were
overlooked.
Reporter #2 (@IndividualGhost1905) confirmed with a UTC+3 host: print
log shows UTC clock value, system date shows local. PrintLogTable is
the "logs/completion time" they called out; the other three are the
same pattern in nearby surfaces.
Replaced the bare new Date(iso) calls with parseUTCDate(iso) from
utils/date.ts — the same helper every other date formatter in the
codebase already uses. It appends "Z" to naive ISO strings and
parses TZ-tagged strings as-is. CameraTokensPage.isExpired got the
same fix because comparing a misparsed Date against Date.now() would
produce false "not expired" / "expired" results around the TZ-offset
boundary.
Reporter #1's printer-card ETA complaint (10:50 + 57m showing 09:48)
is NOT addressed by this fix. That ETA comes from
formatETA(remainingMinutes) which is purely client-side (new Date()
plus minutes from the WebSocket payload, then toLocaleTimeString)
— for it to render UTC the browser timezone itself would need to
be UTC, which is a browser / OS config issue.
Audit confirmed no other regressions: grepped every new Date( call
in frontend/src/. Remaining sites either pass an epoch-ms number,
use the result only for .getTime() arithmetic where the offset
cancels, already wrap in parseUTCDate fallback, or consume a
backend timestamp that includes "+00:00" (FailureDetectionSettings
reads obico_detection.py's tz-aware isoformat).
inline mutation type
POST /api/v1/maintenance/types hard-coded the MaintenanceType
constructor and silently dropped `wiki_url`, so the Documentation URL
field disappeared after save. PATCH worked because it uses
`data.model_dump(exclude_unset=True) + setattr`, which is why editing
a freshly-created type DID save the URL — masking the bug under any
"save then immediately fix it" retest. Reporter @BurntOutHylian
pre-triaged the issue to the exact constructor call at
routes/maintenance.py:206-213; fix is the missing `wiki_url=data.wiki_url`
argument.
Frontend nit from the same report: MaintenancePage.tsx:1131's
`updateTypeMutation` declared `data: Partial<{ name; default_interval_hours;
interval_type; icon }>` — omitting `wiki_url`. The value reached the
API correctly at runtime because `api.updateMaintenanceType` accepts
`Partial<MaintenanceTypeCreate>` (which has wiki_url), but the inline
type lied about the payload shape. Extended the inline `Partial<{...}>`
to include `wiki_url?: string | null`. Pure type fix — no runtime change.
#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.
Two-part fix for the reporter's "removed profiles still show on the slice
menu" symptom.
Local half (real bug). LocalProfilesView's import and delete mutations
invalidated ['localPresets'] (the management view's own query) but not
['slicerPresets'] (the SliceModal's unified preset query, staleTime 60s).
A freshly-deleted preset kept rendering in the slice dropdown until that
staleTime elapsed plus a refocus/remount. Both mutations now also call
queryClient.invalidateQueries({queryKey: ['slicerPresets']}).
Cloud half (opt-in cache bypass). _fetch_cloud_presets keeps a 5-minute
per-(user, token) in-process cache (slicer_presets.py:69, balances
"users see freshly-saved presets quickly" against "busy install doesn't
hit Bambu Cloud once per modal open"). Users delete cloud presets in
Bambu Studio / Bambu Handy, not in Bambuddy, so there's no event hook
to invalidate on. Rather than shorten the TTL globally, the listing
endpoint gains an opt-in ?refresh=true query param that bypasses both
the cloud cache AND the 1-hour bundled-preset cache for that one call;
the fresh result is still written back so subsequent normal callers
keep hitting the cache.
New SliceModal "Refresh" button. Lives in the preset section header
next to the cloud-status banner. Calls getSlicerPresets({refresh: true})
and writes the fresh slots into the ['slicerPresets'] cache via
queryClient.setQueryData so the spinner stops immediately rather than
triggering a second refetch. RefreshCw icon spins while in-flight;
disabled during slice enqueue to prevent double-fire.
The Vitest UI server's /__vitest_attachment__ handler bypasses
isFileServingAllowed via a path-traversal payload, allowing arbitrary file
read/execute on the host. Dev-scope only and not exploitable in
Bambuddy's CI/CLI usage (we don't start the Vitest UI server and
@vitest/ui is not installed), but bumping clears the Dependabot alert
and brings us onto the supported 4.x line.
Bumped:
vitest 3.2.4 → 4.1.8
@vitest/coverage-v8 3.2.4 → 4.1.8
Migration-required fix:
StreamOverlayPage.test.tsx mocked `WebSocket` via
vi.stubGlobal('WebSocket', vi.fn().mockImplementation(() => ({...})))
and the page does `new WebSocket(url)`. Vitest 4 dropped support for
arrow-function constructor mocks ("is not a constructor"). Rewrote
with a plain `function` so `new` resolves correctly.
All 2043 frontend tests pass; npm run build clean; npm audit shows 0
vulnerabilities.
API-key permission gates went from a 17-entry admin denylist with the three
documented scope flags (can_read_status / can_queue / can_control_printer)
enforced only inside /api/v1/webhook/* to an explicit per-Permission
allowlist consulted by every dependency:
- core/auth.py: _APIKEY_SCOPE_BY_PERMISSION maps every non-admin
Permission to one scope flag on APIKey; unmapped = 403.
_check_apikey_permissions now takes the api_key and checks the flag.
- require_any_permission_if_auth_enabled + require_ownership_permission
were returning None for any valid key with zero scope check; both now
invoke _check_apikey_permissions and fail closed.
- Two new scope flags on api_keys: can_manage_library (LIBRARY_UPLOAD /
UPDATE_OWN / DELETE_OWN / MAKERWORLD_IMPORT) and can_manage_inventory
(INVENTORY_CREATE / UPDATE / DELETE / FORECAST_WRITE — required by
SpoolBuddy kiosks). Default TRUE, backfilled from can_queue so existing
"queue-only" keys keep working and hardened "read-only" keys do not
silently gain writes.
- CLOUD_AUTH now routed through can_access_cloud for defence-in-depth
alongside the existing _cloud_api_key_gate.
- Migration column-existence check (_api_keys_column_exists) gates the
backfill so user-edited values are never overwritten on restart.
Structural drift backstop: test_every_permission_has_a_classification fails
CI on any new Permission added without an explicit scope mapping —
prevents the denylist-shape regression that grew the prior surface.
Backend 5469 tests green; ruff clean. Frontend build green; i18n parity
green across 9 locales (5005 leaves each, +6 new keys). Wiki permissions
table + allowlist callout + upgrade notes updated.
Reporter exported a multi-plate .gcode.3mf from Bambu Studio to the
shared folder Bambuddy watches and the 3D preview tab came up empty;
if he re-uploaded the same file via the file manager, the preview
worked. Root cause: two paths classify file_type differently. The
shared-folder scan at backend/app/api/routes/library.py:1343-1348
does a compound-extension check and tags the file `gcode.3mf`; the
upload path at the same file's :1588 does a single `ext[1:]` and tags
it `3mf`. Then frontend/src/components/ModelViewerModal.tsx:71-73 had
hasModel = normalizedType === '3mf' || 'stl'
hasGcode = normalizedType === 'gcode' || '3mf'
Neither matched `gcode.3mf`, so the capabilities object landed with
both flags false and the modal rendered an empty bed.
FileManagerPage.tsx:858 also gated the Preview-3D context action on
`file_type === '3mf' || 'gcode' || 'stl'`, so for shared-folder files
the menu entry didn't even appear, and the type pill at :765-770 had
no colour case for `gcode.3mf` so it fell through to the generic
gray.
Fix (frontend-only, no backend churn):
- ModelViewerModal.tsx introduces an
`isThreeMfFamily = normalizedType === '3mf' || normalizedType === 'gcode.3mf'`
predicate used in two branches — the capabilities check
(`hasModel = isThreeMfFamily || 'stl'`, `hasGcode = isThreeMfFamily
|| 'gcode'`) and the plates-loading branch that previously hard-
gated on `!== '3mf'` and would have returned setPlatesData(null)
for the shared-folder file.
- FileManagerPage.tsx adds `gcode.3mf` to the Preview-3D action gate
and shares the gcode blue type-pill colour so sliced-output files
are visually distinguishable from source 3MFs.
The compound `gcode.3mf` classification on the backend is intentionally
preserved — it carries useful "this is a sliced output" semantics that
other UI surfaces could use later. The `canOpenInSlicer` and
`sliceableType` checks at ModelViewerModal.tsx:269, 277-280 are
deliberately left alone — a sliced output isn't openable in the slicer,
and `sliceableType` already explicitly excludes `.gcode` and
`.gcode.3mf` per the comment.
Out of scope (separate Bambu-Studio format limitation, not a Bambuddy
bug): Vlado's secondary observation that the upload-path 3D preview
"shows only one plate" even though his project has 5 plates — Bambu
Studio's .gcode.3mf export contains the model data and g-code for the
active plate only, not the entire multi-plate project. The print
picker enumerates plates via gcode_*.gcode entries inside the zip
(a separate code path), which is why the user can still pick the
plate at print time. The empty-bed fix is the data point that closes
the user-visible bug.
Reporter assigned a spool to a slot whose stored slicer profile differed
from the new spool's, got the Cancel / Assign Anyway popup, and was under
the impression that confirming the popup just linked the spool in
Bambuddy's DB without pushing the new profile to the AMS — i.e. that he
then had to manually open Configure AMS Slot to fix it. The auto-push has
actually been in place since the assign route existed:
backend/app/api/routes/inventory.py::assign_spool calls
apply_spool_to_slot_via_mqtt after upserting the SpoolAssignment row,
which publishes ams_filament_setting + extrusion_cali_sel over MQTT, and
backend/app/api/routes/spoolman_inventory.py::assign_spoolman_slot does
the same for the Spoolman backend. The only short-circuit is when
firmware reports the slot explicitly empty (tray_state in {9, 10}), in
which case main.py::on_ams_change deferred-replays the configure once a
spool appears. So the popup was friction without revealing what it did.
Two changes:
- frontend/src/components/AssignSpoolModal.tsx and
spoolbuddy/AssignToAmsModal.tsx: profile-only mismatch no longer
fires the popup. The condition becomes
`if (materialMatchResult !== 'exact')` instead of
`materialMatchResult !== 'exact' || !profileMatches`. The 'profile'
member is dropped from the mismatchType union and its standalone
branch in each popup render body is removed as dead code. Material
mismatch still warns — Bambu firmware can refuse the print when the
type is wrong.
- Every firing warning (material, partial, material+profile,
partial+profile) now appends one line via a new
inventory.assignReconfigureNote i18n key:
"The AMS slot will be reconfigured to use the spool's profile."
Real translations across all 9 locales per
feedback_translate_dont_fallback; parity script clean at 4999
leaves per locale.
Reporter wanted to select a transparent filament colour in the spool
editor; CMW-ISS confirmed on v0.2.5b1 that AMS-detected transparent
spools were silently labelled "Black" in the filament-mapping dropdown
because the colour name resolver dropped the alpha byte and the underlying
RGB 000000 HSL-bucketed to "Black". Spoolman already supported 8-digit
hex; the built-in inventory didn't.
Eight collapsing sites fixed together so transparent reaches the user
intact:
- frontend/src/utils/colors.ts: hexToColorName / getColorName /
resolveSpoolColorName / isLightColor short-circuit to "Clear" for
alpha=00 before HSL bucketing or catalog lookup
- frontend/src/utils/amsHelpers.ts::normalizeColor preserves the alpha
byte when alpha < FF (normalizeColorForCompare unchanged so type/colour
matching is unaffected)
- frontend/src/components/spool-form/constants.ts: new
{ name: 'Clear', hex: '00000000' } preset in QUICK_COLORS
- frontend/src/components/spool-form/ColorSection.tsx: hex draft accepts
0-8 chars, commits at 6 (+FF) or 8 verbatim; blur pads 7-char to 8;
selectColor passes 6-char as +FF / 8-char verbatim; isSelected matches
on full rgba; swatch buttons paint a checkerboard for alpha=00
- backend/app/api/routes/printers.py::get_available_filaments preserves
the full rgba on both AMS and vt_tray branches (6-char dedup key
unchanged)
- backend/app/services/spoolman.py::parse_ams_tray drops the silent
00000000 -> F5E6D3FF cream rewrite — the swatch renderer paints a
checkerboard underlay for alpha < FF already (added in #1154), so the
rewrite was hidden technical debt that made every AMS-detected
transparent spool land in inventory as cream
- backend/app/services/spool_tag_matcher.py::create_spool_from_tray
short-circuits the colour-catalog lookup for alpha=00 and stores
color_name="Clear" directly — otherwise an RFID-tagged transparent
Bambu spool would resolve against the #000000 catalog row (or "Black"
via the HSL fallback) before the frontend's resolver ever saw it
- Two shared helpers in utils/colors.ts — getSwatchStyle(rgba) (style
object: checkerboard for alpha=00) and spoolColorString(rgba)
(8-char hex string for SVG fill) — applied to every simple-swatch
site that would otherwise have rendered Clear spools as solid black:
LabelTemplatePickerModal, SpoolBuddyInventoryPage (SpoolCircle + dot),
SpoolBuddyAmsPage (both branches), SpoolBuddyWriteTagPage (4 sites),
ForecastPanel, AssignToAmsModal, AssignSpoolModal (both branches),
InventorySpoolInfoCard, TagDetectedModal, SpoolInfoCard, LinkSpoolModal,
and the FilamentSwatch tooltip title fallback
Intentionally NOT changed: native <input type="color"> keeps 6-char hex
(can't pick alpha; onChange still emits +FF, correct); Spoolman's
_find_or_create_filament strips alpha (Spoolman catalog is 6-char only);
print_scheduler colour matching strips alpha (auto-mapping treats Clear
as Black for slot compatibility); label_renderer prints "#RRGGBB" on the
physical label (printers can't print transparency, swatch fill via
_color_from_hex still honours alpha).
maziggy