mirror of
https://github.com/maziggy/bambuddy.git
synced 2026-09-30 11:12:35 +02:00
eda86e5198b0e185d10eaba7f4fefe83e7220607
1145
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 maziggy
|
f421bb8160 |
Show the picked preset's real values in the process-settings panel
The panel baselined every field on the option schema's compiled-in
defaults, so a preset setting a 0.42mm line width displayed 0 -- the C++
default meaning "derive from the nozzle". Every field was affected; the
Line width group just made it obvious.
Bambuddy cannot answer this itself. A standard-tier pick is only an
{inherits: ...} stub on our side, and local/cloud presets are deltas whose
remainder lives in the profile tree bundled inside the running sidecar.
The values now come from the sidecar's POST /profiles/resolve, which runs
the same resolver /slice does against the same profiles, so what the panel
shows cannot disagree with what a slice produces. Deliberately not the
local orca_profiles resolver: it walks OrcaSlicer's published tree, which
can differ from the image actually installed.
An untouched field shows the preset's value and reverting returns to it.
isModified compares against that baseline too, so fields the preset moved
off the C++ default are no longer flagged as user edits, and values nobody
typed are no longer sent. When the values can't be read -- sidecar offline
or older than the endpoint -- the panel falls back to schema defaults and
says so rather than presenting them as the preset's.
Row layout, from screenshots:
- The control column is anchored to the right edge at a fixed width. It
had been packed left after a fixed label column, leaving the values
stranded mid-container with dead space beside them.
- Units are no longer truncated to "mm o...". The cap fitted the common
"mm" but not "mm or %" or "mm/s² or %".
- The "from file" tick moved ahead of the control it qualifies; it used to
sit past the unit at the row's right edge, reading as unrelated.
Both the unit and the control keep fixed widths, and the tick's slot is
reserved on rows without one -- sizing any of them to content makes each
row's input land at a different x and the column comes out ragged.
Also fixes a field that could not be cleared: emptying a free-text input
dropped the key, so it snapped back to the baseline and retyping appended
to it ("0.42" + "0.5" = "0.420.5"). The number branch was fixed earlier;
the text branch -- coFloatOrPercent, coString, the vector types -- was
not, and the regression test used a number input so it never caught it.
Requires a sidecar built from orca-slicer-api 4b664b7 or later. Older
images 404 the endpoint, which is handled as the fallback above.
|
||
|
maziggy
|
c384911f7c | Sync | ||
|
maziggy
|
2368445378 | Changed layout | ||
|
maziggy
|
f0500578bd |
Edit the full print-parameter set from the slice dialog
Slicing from Bambuddy meant taking a process preset as-is; any change meant a round trip through Bambu Studio. The slice dialog now carries OrcaSlicer's full process tree -- pages, groups, labels, tooltips, ranges and defaults extracted from the slicer's own sources. Enable/disable rules are evaluated from the slicer's own enable_if expressions via a recursive-descent interpreter (no eval, CSP), with enum comparisons validated against each option's declared values. Anything undecidable leaves the field editable rather than greyed. Overrides apply after the source's support config (#1881) and the designer's carried tweaks (#2622), so an explicit choice always wins; an untouched panel sends the same request as before. Adds slice_engine as a separate setting from preferred_slicer -- where slicing runs is a different axis from which binary the sidecar drives. Only the sidecar engine is registered, so no picker renders yet. |
||
|
maziggy
|
c8e5ecc23a |
chore(deps): clear every npm audit and pip-audit finding
Frontend: - react-router/-dom 7.18.1 -> 7.18.2. The RSC-mode CSRF advisory was carried as a documented exception in the audit gate because its only fix was the 8.3.0 major; upstream backported it, so the exemption lapsed on its own -- an entry only holds while fixAvailable.isSemVerMajor is true. The allowlist is now empty; the machinery stays for the next one. - dompurify 3.4.12 -> 3.4.13. Ships in the app, but the path is unreachable: no hooks registered, IN_PLACE never used. - js-yaml override ^4.3.0 -> ^5.2.3 (fix not backported below 5.x, so a major) and nanoid override ^3.3.18. Both dev-only, via eslint and postcss. eslintrc calls only load(), on the legacy .eslintrc.yml path this repo does not use; eslint, vite build and 2861 frontend tests pass on it. Backend: - cryptography >=48.0.1 -> >=50.0.0, aiohttp >=3.14.0 -> >=3.14.3, pyopenssl >=26.3.0 -> >=26.4.0. CI resolves from scratch and was already installing the fixed releases; the floors cover the case CI does not, an existing venv where >= is satisfied and `pip install -r` upgrades nothing. pyOpenSSL has to move with cryptography -- each release caps it to a narrow window, so a stale pyOpenSSL pins cryptography below its own fix line. |
||
|
maziggy
|
328bac450a |
Stop auto-drying re-arming into a threshold it can never reach (#2770)
An H2D armed five 12-hour drying cycles inside four hours, one of them six seconds after the previous one ended, and none ran more than a couple of hours. Two things combine. The firmware ends a cycle when it decides the filament is dry rather than when the clock runs out, and reports no fault doing it -- across this printer's history the run length tracks how wet the spools were, from nearly the full 12 hours starting at 32% down to minutes once the unit sat at 10-13%. That part is the AMS doing its job. The loop is ours. An AMS reports higher relative humidity while it is warm than once it has cooled: the same unit read 10-13% cold and 15-20% through every cycle. With the threshold at 14% the reading at the moment a cycle ended was always still above it, so the next 30-second pass armed another 12-hour cycle. Nothing counted, nothing waited, and it only stopped when the box finally cooled enough to read 13%. Auto-drying now waits 30 minutes after a cycle ends before arming another on the same unit, and gives up on a unit after two consecutive cycles that bring the reading no lower -- logging why and sending a new notification, on by default because it reports that Bambuddy has stopped acting. Progress is judged against the lowest reading any cycle on that unit has ended at, not against the threshold, so a genuinely wet spool in a humid room coming down 40-37-35 keeps drying however far it still is from the target; comparing against the best so far rather than the previous end stops a sensor wobbling by one point reading as progress every other cycle. The suspension lifts by itself once the reading falls below the threshold. Neither guard can stop a running cycle, and a cycle Bambuddy cut short for a print, or that the user stopped by hand, is not counted against the unit -- so a farm that dries between queue jobs is unaffected. The threshold field now warns below 20%, and every cycle end logs the unit's temperature and humidity, which is what made this diagnosable. The same bundle showed unrelated tasks failing with "database is locked", each inside a 30.000-second Discord connect timeout. Alarms are raised from inside the loop that records sensor history, at a point where the new rows are added but not committed; the first read in the notification path flushed them to satisfy itself, opening a write transaction, and the provider was then contacted over the network with that transaction still open. SQLite allows one writer and 30 seconds outlives the 15-second busy timeout, so every other write in that window failed. The two reads that run before a provider is contacted no longer flush the caller's pending work, and the connect timeout is 5 seconds rather than 30 -- the body keeps the full 30, so image uploads on a slow uplink are unaffected. SQLite only; Postgres has no single-writer limit. |
||
|
maziggy
|
04009a5c6a | Post work PR #1448 | ||
|
maziggy
|
595dc5844a |
Say which header blocked the 3D preview, instead of leaving the browser's page (#2787)
A reporter uploaded an STL, sliced it in Bambuddy, and got a frowny icon and
"<hostname> refused to connect" when previewing the sliced file -- while the
STL's own preview worked. That is Chrome's ERR_BLOCKED_BY_RESPONSE page, drawn
inside our layout shell, and the split between the two previews is where the
cause is: an STL or source 3MF renders in the page, a sliced file opens the
embedded G-code viewer, which is the only thing in Bambuddy that frames a
Bambuddy page (FileManagerPage.tsx:2472, GCodeViewerPage.tsx:47).
Our headers permit that frame -- frame-ancestors 'self' plus SAMEORIGIN on
everything under /gcode-viewer (main.py:7709) -- and the frame is same-origin,
so a refusal means a stricter header was added after we replied: a reverse
proxy, a security add-on, an auth gateway. None of which the user could see.
The browser drew its own page and nothing said what was refused, by whom, or
that the viewer opens perfectly well in a tab.
The frame cannot report this itself. A frame blocked by X-Frame-Options or
frame-ancestors still fires onLoad -- the browser commits an error document --
so there is no failure to catch. The page now asks for the same URL directly:
same-origin, so every response header is readable, and it goes through whatever
proxy the browser reaches Bambuddy by.
findFramingRefusal reads the verdict the way a browser does. frame-ancestors
wins outright when present, because CSP requires X-Frame-Options to be ignored
in that case -- reading both would blame a proxy-added DENY the browser never
consulted. Multiple CSP headers are intersected and fetch joins them into one
comma-separated string, so every frame-ancestors occurrence has to permit us,
not just the first; that is the shape a proxy appending its own policy to ours
actually takes. Failing that, a legacy header that is anything other than a
single SAMEORIGIN refuses us, including the conflicting "SAMEORIGIN, DENY" that
appears when a second copy is appended.
On refusal the frame is replaced with the header named verbatim, so an operator
can go and find the rule in their proxy config, and a link that opens the viewer
in its own tab -- a top-level page, which no framing header applies to. A
non-200 is reported the same way rather than as raw {"detail":"Not Found"}
inside the frame, which the startup-time warning at main.py:8120 already calls
out as easy to miss. A probe that cannot reach a verdict changes nothing: the
iframe stays, because guessing at a cause we cannot see is worse than the
browser's own page.
The working case is unaffected -- the iframe renders immediately as before and
the probe only ever replaces it.
|
||
|
maziggy
|
f5fbae45a3 | Housekeeping | ||
|
maziggy
|
3f218729b9 | . | ||
|
maziggy
|
604fa44593 |
Explain Bambu Cloud's CAPTCHA challenge instead of repeating it (#2790)
A reporter tried to connect to Bambu Cloud and got "We need you to confirm you
are not a robot" as an error toast, with no CAPTCHA anywhere to answer and
nothing to click. That sentence is Bambu's, not ours. Their anti-abuse layer had
flagged the network and was answering the sign-in with HTTP 418 and a challenge
body: {"captchaId": "...", "error": "We need you to confirm you are not a
robot"}.
Bambuddy had no idea what that was. The reply is well-formed JSON, so
_detect_cloudflare_challenge -- which triggers on an unparseable body, CF
markers, 403+cf-mitigated or 503+cf-ray -- never fired on it, and login_request
fell through to its generic error path, which lifts data["message"] or
data["error"] out and hands it to the UI verbatim. The user was left to conclude
their password was wrong or that Bambuddy was broken. Four sign-in attempts
inside eighteen seconds appear in their log, each one more evidence for the
thing that had flagged them.
is_captcha_challenge matches on the 418 status plus a challenge marker in the
body -- captchaId is the reliable one, the wording is matched too because Bambu
has shipped it under more than one phrasing. A bare 418 with no marker is
has shipped it under more than one phrasing. A bare 418 with no marker is
deliberately NOT reported as a CAPTCHA: telling someone to solve a challenge
that was never offered is the exact confusion this issue is about.
login_request, verify_code and verify_totp now return reason="captcha" with an
explanation covering the three things the reporter had no way to find out: the
credentials are not the problem, the block is keyed to the public IP address
rather than the account, and it clears by itself within a few hours.
Sign-in requests are then held back for 300s so Bambuddy stops deepening the
block. Keyed per origin, not per service: TOTP verification posts to
bambulab.com while everything else posts to api.bambulab.com, and a challenge
seen on one must not strand somebody halfway through a two-factor sign-in on the
other. Entries expire on read, so the map cannot grow past one per region. The
token endpoint is deliberately left ungated -- it is the way out.
The UI shows a persistent panel rather than a toast. A toast names a problem the
user cannot act on and then vanishes; this one stays put and carries a one-click
route to "Use access token instead", which is the only thing that works while
the challenge lasts, since that path does not touch the challenged endpoint.
MakerWorld meets the same challenge from the same edge and now shares the
detection. It used to require the literal word "robot" in the error text and
reported any other wording as an unexplained block.
The System Health scanner gets a bambu-cloud-captcha signature. The reporter's
bundle came back with zero findings while their log was full of the failure.
Its advice for a failed FTPS handshake was corrected at the same time: it still
blamed firewalls and outdated firmware, which the #2780 investigation ruled out
last release -- it is the printer's own file service wedging, and the fix is to
restart the printer. The wiki said so already; the health panel did not.
|
||
|
maziggy
|
91acac2b35 |
Stop retrying a printer whose FTPS handshake fails, and name the cause (#2780)
Two printers went on printing while every archive they produced held nothing but a filename. Bambuddy opened port 990, the printer accepted the connection and answered with something that was not TLS, and connect() logged a warning and returned False -- indistinguishable, to every caller, from "the file is not at this path". So the 3MF lookup walked all six filename variants across five directories with four retries each, the cover endpoint ran its own sixteen-path sweep, and the timelapse scan added four more, all against a sixteen-path sweep, and the timelapse scan added four more, all against a printer that could not have answered any of them. One reporter's log carried 1813 identical handshake failures, another's 3511. The evidence says this is the printer's own file service getting stuck, not a model, firmware or TLS-configuration problem. In #2780's bundle the same two printers ran clean from 22 July to 4 August and failed again from the 5th; a second bundle shows an X2D serving files for five days, flipping on 19 July, then failing every connection for eight days with zero successes. The same models and firmware appear in roughly twenty other bundles with no occurrences at all. Both bundles show it happening with cap_tls_v1_2 in effect -- the X2D and H2C entries in ftp_profiles were added on analogy with P2S to fix exactly this symptom, and the reporter's own debug line proves they do not. An ssl.SSLError from connect() now opens a five-minute cool-off for that printer. Subsequent connects return False without touching the network, so a wedged printer is contacted twice an hour instead of hundreds of times a minute, and the single warning that is logged names the remedy. The cool-off is dropped on expiry rather than kept, so the map holds one key per currently wedged printer. ftps_handshake_blocked() lets the sweeps stop: the 3MF lookup abandons the remaining paths and skips the directory-walk fallback, the cover endpoint returns 503 naming the file service instead of a 404 that reads as "this print has no thumbnail", and the timelapse scan separates 503 (cannot reach the printer) from 404 (no timelapse directory) -- one 500 used to cover both, which is what the reporter hit when reproducing. The Connection Diagnostic completed a bare TCP connect to 990, which is why it reported the port green throughout: the port is open, it is what is behind it that is broken. It now completes a real implicit-TLS handshake using the model's own ftp_profiles cap, so a pass means the FTP client would also get through. An open port that cannot negotiate reports warn with reason no_tls, selecting a new message in all 13 locales that points at a printer restart rather than at the firewall. No login is attempted, so this stays valid in the pre-save Add Printer flow. The cool-off tests run against a real socket that accepts on 990 and replies with a plaintext FTP banner, reproducing WRONG_VERSION_NUMBER rather than mocking ssl. The autouse fixture clearing _mode_cache now clears the cool-off map too -- every test here talks to 127.0.0.1, so one left behind would make the next test's connect() a no-op. |
||
|
maziggy
|
306b9ba7fd |
Accept Forgejo tokens scoped to a single repository (#2775)
ForgejoBackend.test_connection asked GET /user who the token belonged to
before asking whether the token could reach the repository, and treated a 403
there as fatal. A Forgejo v15 repository-scoped token may only carry
read/write on issues and repositories, so it 403s on /user -- and was rejected
despite reaching its own repository fine, which is all a backup needs: the push
path uses the Contents API and restore reads commits, trees and blobs, all
under /repos/{owner}/{repo}. That /user call was the only one in the whole
provider layer.
The probe stays, because a 401 from it is genuinely conclusive and names a bad
token before the repo call has to guess -- Forgejo v15+ hides a private repo
behind 404 rather than 403, so the repo call cannot always tell those apart.
Every other status now falls through to the repo check.
Two additions keep the messages as sharp as before: the repo call's own 401 is
mapped to "Invalid access token" instead of a generic API error, and the 404
names write:repository and the scoped-to-another-repository case, mentioning a
possibly-invalid token only when /user did not confirm the identity.
The token hint under the field was one shared string reading "fine-grained
token with Contents read/write" -- GitHub's advice, shown to Gitea, Forgejo and
GitLab users too. It is now per provider via PROVIDER_TOKEN_HINT_I18N_KEY,
following the existing repo-URL placeholder map, translated in all 13 locales.
Tests pin the repository-scoped token connecting, a transient /user status not
blocking the repo call, both 404 wordings, and the repo-call 401; a frontend
test switches providers and asserts the hint follows.
|
||
|
maziggy
|
afa0ba0dc0 |
Nest projects under a master project and roll their figures up (#1264)
Projects were flat. The parent_id column and the sub-project list existed but nothing could set a parent outside the API, and a master project's stats only ever covered its own prints. The project dialog gets a parent picker, and a project with sub-projects gets a second card covering the whole tree -- jobs, parts, time, filament, cost, and progress against every target in the tree added together. That card is separate from the project's own stats, which keep their existing meaning; widening them would have restated the figures of anyone who had already nested projects over the API. Each listed sub-project carries its own branch's roll-up, so the rows add up to the card above them. On the Projects page a sub-project is drawn inside its parent's group rather than as another card in the grid -- two cards columns apart cannot show that they belong together, whatever the caption says. A sub-project whose parent the status filter has hidden stays put and names its parent instead. compute_project_stats now goes through the same grouped aggregation as the roll-up rather than its own copy of the SQL, since the two must agree. Three things the interface made reachable: - PATCH refused only a project as its own direct parent, so A -> B -> A was two calls away. A cycle has no root to roll up to, and the walk keeps its seen-set for databases that already contain one. - A sub-project's percentage was completed quantities against the plate target, disagreeing with the page it linked to. - Deleting a mid-tree project orphaned its children at top level; they now move up to its own parent. |
||
|
maziggy
|
b5163b94f8 |
fix(backup): report the categories a failed restore already committed (#2656)
The service reports what landed on a part-way failure -- categories commit as they finish, so results names the ones on disk -- and the modal gated the whole result panel on success, so it showed the failure message and dropped them. The cache invalidation was inside that same branch, which is the half that mattered: a run that committed the settings category and then failed left the app rendering pre-restore settings, with no reload and no re-read, which is the failure the modal's own reload-on-close exists to prevent. Gate on what was written instead. A refusal that never reached a category still carries an empty results and still keeps the form, so the mutex and backup-in-flight cases are unchanged. A partial does not read as a success: the tick becomes a warning and a line says the listed categories are the ones on disk. --- fix(backup): keep the local owner when the backup names one we cannot resolve (#2656) An owner the backup names but this instance has no user for was written as NULL, and overwrite is a blanket setattr -- so restoring over a local archive that had a perfectly good owner took it away, which is the 404-for-its-own- owner failure this column is carried across to fix. Resolving by username widened the trigger from a stale id to any user renamed since the backup. It is the same state as an absent key: the backup has not told us who owns this. So it takes the same action -- the column is not written at all. Overwrite keeps the local owner, insert lands ownerless with the note, and an explicit null still writes, so overwrite still means "match the backup". The notes move to the insert path with it. On overwrite nothing was taken away, so there is nothing to warn about, which is the rule the absent-key case already follows. |
||
|
MartinNYHC
|
6cd81fcd85 | Merge branch 'dev' into feature/2656-restore-from-github | ||
|
maziggy
|
1eea194953 |
Resolve a spool's material to a known drying preset before starting a cycle (#2774)
The drying popover prefilled its material from the loaded spool without checking the preset table had that material. An AMS-HT holding Support for PLA/PETG (tray_type PLA-S) fell back to PLA's temperature but kept PLA-S as the material, and the dropdown displays its first option when handed a value outside its list -- so it read PLA while PLA-S was sent. Same gap for every composite: PETG-CF prefilled at PLA's 45C. Resolve the tray_type to a key the table has before setting either value. Support materials and composites resolve to their base, nylon is aliased under its several spellings, and anything unrecognised falls back to PLA -- the coolest row, so an unknown material under-dries rather than deforming a PLA spool. Also record request-topic messages in the MQTT debug log. That topic carries every command a printer is given, including Bambu Studio's, and returned before the logging block -- so a capture could show only what the printer said, never what it was told. |
||
|
jmoore-skild
|
a71b30f1fc |
build(frontend): rebuild static/ on the merged tip (#2656)
One build on the tip after merging dev, per the branch'"'"'s standing rule that intermediate commits carry a stale bundle and only the tip has to be right. dev'"'"'s CSS moved to index-Db2rfQf-.css while this branch was out; the rebuild lands on the same hash, so static/index.html differs from dev by the script line alone again. |
||
|
jmoore-skild
|
b34ea64417 |
build(frontend): rebuild static/ so the restore UI actually ships (#2656)
The dev merge took dev's static/index.html, which loads the pre-restore bundle, and left both bundles tracked. Merged as-is none of the frontend shipped: no Restore button, no modal, no Type column. Rebuild drops the superseded bundle and points index.html at a single one that carries restoreFromGit and this round's new note leaf. The CSS hashes identically to dev'"'"'s, so index.html differs by the script line alone. |
||
|
maziggy
|
3bbe00784f |
Write printer status straight through while the tab is hidden (#2754)
Removing the requestAnimationFrame wrapper fixed the total stall but left the 100ms coalescing timer in the path, and a hidden page's timers are clamped to once a second at best -- once a minute past five minutes hidden. The reporter still saw a tab title at 2% beside a page at 40%. The coalescing guards against a render cascade, which a hidden tab cannot have, so it is skipped there and kept while visible. The existing hidden-tab tests advanced fake timers, which simulates the timer the browser was throttling; the new one never advances the clock. |
||
|
maziggy
|
cd004df817 |
Show Home Assistant sensors on the printer card (#1148, #448)
Binds binary_sensor and reading-carrying sensor entities to a printer and renders their state on its card, worded by Home Assistant's device_class. Optional per-sensor alert condition drives a notification on the transition into the alert state and an opt-in interlock that holds queued prints while alerting -- a hold with a readable waiting_reason, never a failure, and only ever on a sensor that was read successfully. Sensors get their own table rather than a wider entity pattern on SmartPlug: get_smart_plug_by_printer would otherwise hand the card's power button a door contact to switch. The hold is passed to the model matcher directly rather than merged into busy_printers: _check_auto_drying reads that set as "is currently printing" and would put an idle-but-held printer down the mid-print drying path. The notification_providers migration spells its default FALSE, not 0 -- Postgres rejects an integer default for a boolean and _safe_execute swallows the error. |
||
|
maziggy
|
fb4c130bb2 |
fix(slicer): drop the legacy library:read from the slice gate (#2725)
The desktop handoff accepted library:read alongside read_all/read_own, on the reasoning that default groups do not carry it and requiring it would lock out Operators and Viewers. The permission grants nothing in that position: the slicer-token endpoint gates on require_ownership_permission(LIBRARY_READ_ALL, LIBRARY_READ_OWN), and neither that dependency nor User.has_permission expands the legacy name, so a group holding only library:read gets a 403 there. It cannot reach the File Manager to try, either - GET /library/folders gates on the same pair - and the library:read -> library:read_own migration in core/database.py runs only over the groups named in DEFAULT_GROUPS, so a custom role that still carries it stays stuck rather than being upgraded. custom role that still carries it stays stuck rather than being upgraded. Accepting it only enabled a menu item the server refuses, and the failure is indistinguishable from "no slicer installed" once the catch hands the unauthenticated URL over. Removed, with the comment recording the reason so the next reader does not re-add it, and a test that pins it. --- refactor(slicer): share one sliceable-file-type rule (#2725) The File Manager and the 3D preview decide the same thing about the same file and each held its own list of extensions - which is how they came to disagree, offering a desktop handoff for an STL whose own preview showed "Open in Slicer" greyed out. Making the two lists identical fixed the symptom and left the drift, so SLICEABLE_FILE_TYPES now lives in utils/slicer.ts with isSliceableFileType for a stored file_type and isSliceableFilename for a name. The filename form still rules out the compound extensions explicitly, since .gcode.3mf ends with .3mf; the type form does not need to, because classify_file_type stores that one whole. Both test files mocked the whole slicer module, which would have replaced the new predicates with undefined - switched to importOriginal so only openInSlicer is stubbed. That is the better shape regardless: the tests now exercise the rule the component runs instead of a copy declared beside them. Carries the rebuilt bundle. The CSS hash moves with it - the split button introduces Tailwind classes the previous build had no reason to emit. |
||
|
MartinNYHC
|
f85e3e7fa1 | Merge branch 'dev' into feature/2656-restore-from-github | ||
|
maziggy
|
fce7ea0200 |
Stop the drying badge inventing a temperature on a uniform AMS (#2759)
The follow-up to the same report: a second AMS 2 Pro, no aux power, loaded entirely with PLA and drying at the 45C the reporter picked, showed 45C and then switched to 55C. Bambu never echoes back a cycle's filament or temperature, so both come from the target cached when the command went out, and the fallback for a missing cache reads the loaded trays. The first pass narrowed that fallback to units whose spools agree on a filament, which fixed the mixed-unit case in the original report but left the uniform case answering with the spools' RFID-recommended drying_temp -- 55C here. Agreement across slots is evidence of what is being dried, because the dryer heats all of them. It is no evidence of the temperature, which is picked freely in the popover, so the recommendation was never more than a guess wearing the same confident "PLA @ 55C" as a known target. uniform_tray_drying_hint therefore becomes uniform_tray_filament_hint and returns the filament alone. The badge names a temperature only when we sent it, and otherwise shows the filament and the countdown. Both status builders also stopped filling the two fields independently. Entering the fallback when either was missing let a cached filament pair with a guessed temperature and render as though both were known; the temperature now simply has no fallback to reach. The badge required both fields before rendering anything, so dropping the temperature would have blanked it rather than shortening it -- the frontend now renders each on its own terms. No new translation key: the filament type is a passthrough. This changes what is shown when the cached target is missing, not why it goes missing. If the reporter was on the fixed build, the falling- edge gate is still letting a zero through on an unpowered unit, which needs a log covering the start of the cycle. |
||
|
jmoore-skild
|
0cf5b8da41 |
fix(backup): tell a restore apart from a backup in Backup History (#2656)
A restore writes a `github_backup_logs` row too — same table, same status values, and it already carried `trigger: 'restore'`, which the API already returned. The history table rendered date / status / commit only, so the row read as a successful backup dated now while "Last backup" said something else: `last_backup_at` is only stamped by an actual backup, and the two disagreeing is alarming with nothing on screen to explain it. Adds the Type column the trigger was always there to fill. Unknown values fall back to the raw string rather than rendering blank, matching the `backup.pathCheck.*` lookup a few hundred lines up — a trigger kind added later shows up as itself instead of vanishing. Backend unchanged: it has recorded this correctly since the restore path was written. Three tests, all three failing without the column. 13 locales in parity at 5776 leaves — pt-BR takes "Backup manual" rather than the parenthesised form because "Backup (manual)" is identical to en, which the parity check counts as untranslated. Bundle rebuilt: `index-DhOfNgMz.js` → `index-CadgB7UN.js`. It also picks up the `archivesOwnerUnknown` leaves from the previous commit, which changed i18n without rebuilding. |
||
|
jmoore-skild
|
3bb087db54 |
fix(backup): report the rows a failed K-profile step already committed (#2656)
`_apply` commits the database categories before the K-profile phase, and the
comment there is right about why: `get_kprofiles` is 3 x 5 s per printer per
nozzle and SQLite's `busy_timeout` is 15 s, so holding the writer across the
MQTT phase would fail every concurrent writer in the app.
But `run_restore`'s handler returns `{"success": False, ..., "results": {}}`
for anything raised after that point, and the per-call guards inside
`_restore_kprofiles` do not cover the whole phase. Two consequences, and the
second is worse:
* The user is told the restore failed and handed an empty `results` while the
archive, spool and settings rows are durable on disk. The honest-reporting
theme this whole feature is built on inverted on exactly the path where it
matters most.
* `_reconfigure_mqtt_relay` sits inside the same `try`, downstream of the
raise. A restore that rewrote the mqtt_* rows left the relay pointed at the
pre-restore broker until something else reconfigured it.
`_apply` now contains the K-profile phase: fold the error into that category's
tally as `failed` plus a `kprofilesStepFailed` note, and let the results it has
already committed be returned and reported. Every profile the payload carried
and the phase did not account for is counted failed — silence would have been
the same lie in a smaller font. `_reconfigure_mqtt_relay` is reached again
because `_apply` returns normally. The rollback in the handler discards only
the phase's own read transaction, so a database error cannot leave the session
in a state that turns the caller's commit into the very report this prevents.
`kprofilesSendFailed` was the obvious note to reuse and is the wrong one: it
names a nozzle, a printer and a serial that a phase-level failure does not
have, and "failed to send" is untrue of a step that never got as far as
sending. One new leaf x 13 locales instead.
Belt-and-braces on the trigger that found this:
`sum(len(c.get("profiles") or []) ...)` raises TypeError on a hand-edited or
truncated backup whose `profiles` is not a list, and it runs before the guards.
Counting defensively makes that a skipped category rather than an exception
thrown over committed rows.
Control kept explicit: a failure *before* the commit still rolls back, still
reports nothing restored, and still does not touch the relay.
Tests: +5 (280 -> 285 across the three restore files, 328 -> 337 across
`-k github`). Fail-pre-fix 4 — 3 for the containment, 1 for the defensive
count, checked separately. i18n parity 13 locales at 5771 leaves.
Bundle rebuilt for the new leaf: index-CHCEEMgx.js -> index-DhOfNgMz.js. CSS
hash unchanged.
|
||
|
jmoore-skild
|
df6656a0a9 |
fix(backup): drop the settings-pin workaround, upstream fixed the cause (#2656)
This modal carried two workarounds for #2716: `onSuccess` deliberately did not invalidate `['settings']`, and a query-cache subscription pinned the entry to the pre-restore copy for as long as the result panel was up. Both existed because SettingsPage's debounced auto-save diffed its `localSettings` form state against the live cache, so any refetch of a restored settings row -- this modal's, a window refocus, a reconnect, or any of the ~30 other observers of the key -- read as an edit and PATCHed the pre-restore values back over the restore about 500 ms later. `43cb216a` on dev fixed that. The page now keeps a server baseline and reconciles a moved snapshot field by field: an untouched field adopts the server's value instead of overwriting it. The restore no longer needs an exception, and maziggy explicitly invited dropping it. A commit on top rather than a rebase-drop of `21bb5afc`: later commits touch this file, and the workaround was right when it was written. This says so. The reload on close stays -- it was never one of the two workarounds. Its stated reason was, though, and it was the #2716 bug, so it is restated for what it actually buys: invalidating `['settings']` only resyncs what reads that query, and the interface language, currency and auth toggles are read on boot. Tests: "never invalidates the settings query" inverts; the pin test and its control go with the pin. The reload pair stays. 28 -> 26 tests in this file. Bundle rebuilt: index-CCCWDEkl.js -> index-CHCEEMgx.js, carrying this, J1's locale leaf and the reworded ack caveat. CSS hash unchanged. |
||
|
maziggy
|
78cbd82259 |
Scale the printer card's body text and icons with its size (#1848)
Switching a card from M to XL made it wider, enlarged the printer name and the thumbnail, and left everything else where it was. The AMS slot labels, temperatures, filament names, status text and every small button stayed pinned between 8 and 11 pixels -- under the smallest size used anywhere else in the app -- so a full-width card carried the same tiny text as the compact one. Browser zoom does not answer this: it enlarges the whole page and so preserves the very disparity being reported. The card root now carries ten custom properties derived from cardSize, and the 200 fixed sizes in its subtree reference them: text-[10px] becomes text-[length:var(--pc-t10,10px)], w-3 h-3 becomes w-[var(--pc-i3,0.75rem)]. L draws the body 20% larger and XL 40%, icons included, so the controls grow with the text instead of staying fiddly to hit. Custom properties rather than an em-based root font-size. Setting font-size on the card would silently reshape any text that declares no size of its own, and would break for portalled content. Each converted class names its old fixed value as the fallback, so anything rendering outside a card root is untouched -- which is what leaves the portalled temperature popover exactly as it is. Its four sites stay fixed on purpose, as does the page chrome; the conversion was scoped from the function declarations rather than line numbers, and afterwards only those four intended sites still hold a literal px value. S and M stay at 1.0. S is the dense fleet view where density is the point and M is the default, so an existing install looks identical until the user reaches for a size that is already asking for more room -- the same control the request asked this to follow. The AMS-HT card needed separate work, because its temperature and humidity readings sit beside the slot rather than under it. That single slot was the only growable item on its row, so it took every spare pixel and pushed the readings hard against the card's edge; it is now capped at roughly two ordinary slots, which keeps them clear at any card width. The card itself is capped at one full AMS card's width, so a unit that wraps onto a line of its own no longer stretches that slot across the whole card. The AMS slot minimums are deliberately NOT scaled. Raising them was tried and reverted: those cards already grow to fill their row, so 3.5rem is a floor they sit well above, and raising it only cost a unit its place on the row -- which is what pushed the AMS-HT onto a line by itself and exposed the stretching above. A test pins them at 3.5rem at XL so this reads as a decision rather than a missed spot. |
||
|
maziggy
|
45b678692c |
Scale the printer card's body text and icons with its size (#1848)
Switching a card from M to XL made it wider, enlarged the printer name and the thumbnail, and left everything else where it was. The AMS slot labels, temperatures, filament names, status text and every small button stayed pinned between 8 and 11 pixels -- under the smallest size used anywhere else in the app -- so a full-width card carried the same tiny text as the compact one. Browser zoom does not answer this: it enlarges the whole page and so preserves the very disparity being reported. The card root now carries ten custom properties derived from cardSize, and the 200 fixed sizes in its subtree reference them: text-[10px] becomes text-[length:var(--pc-t10,10px)], w-3 h-3 becomes w-[var(--pc-i3,0.75rem)]. L draws the body 20% larger and XL 40%, icons included, so the controls grow with the text instead of staying fiddly to hit. Custom properties rather than an em-based root font-size. Setting font-size on the card would silently reshape any text that declares no size of its own, and would break for portalled content. Each converted class names its old fixed value as the fallback, so anything rendering outside a card root is untouched -- which is what leaves the portalled temperature popover exactly as it is. Its four sites stay fixed on purpose, as does the page chrome; the conversion was scoped from the function declarations rather than line numbers, and afterwards only those four intended sites still hold a literal px value. S and M stay at 1.0. S is the dense fleet view where density is the point and M is the default, so an existing install looks identical until the user reaches for a size that is already asking for more room -- the same control the request asked this to follow. Wiki notes the scaling in the card-size table and why it differs from browser zoom. Tests pin the variable values at every size, including that S and M still emit the pre-change sizes. |
||
|
maziggy
|
3db8ac9da7 |
Let the external spool be hidden from the printer card (#1782)
An external spool holder that never gets used still takes a full card's width in the Filaments row, next to the AMS units that are actually in use. An eye icon at the right-hand end of that row's header now hides it, and clicking it again brings it back -- the affordance stays in place rather than moving to a settings page, so the choice is discoverable and reversible where it applies. Per printer rather than global. A global flag would suit a toolbar button, but an icon on the card that silently rearranged every other card would surprise; it is keyed by printer id in one localStorage entry, the same shape as printerCollapsedSections, and sits alongside the other browser-local printer-page view preferences. The toggle is offered only when the printer has at least one AMS. On a machine with no AMS the external spool is the entire filament section, so hiding it would leave an empty row with no control to undo it. The icon and the hide condition read the same canHideExternalSpool, so a preference stored before an AMS was unplugged cannot blank the row either -- the spool reappears instead. The store lives in a new utils/printerCardPrefs.ts rather than in the 9,157-line page. It re-reads before writing so two cards toggled in one session cannot clobber each other's entry, deletes the key instead of storing false, and treats a malformed or unavailable localStorage as "nothing hidden" so a private-mode browser cannot throw out of a render. |
||
|
maziggy
|
9bc96aeb83 |
Hold error and warning toasts for twice as long
Every pop-up notification auto-dismissed after three seconds regardless of what it said. That suits "Settings saved" -- a confirmation of something the user just did, skimmed rather than read -- but errors and warnings are a different kind of message. They carry a reason, often one relayed from the printer or the backend, and they run to a couple of lines. Three seconds was not enough to finish reading one, and there is no notification history to go back to once it slides away. Errors and warnings now hold for six seconds; success and info keep the three-second default. The duration was a bare literal in showToast and is now derived from the toast type, with the long window expressed as twice the base so the two cannot drift apart if the base is retuned. showPersistentToast never had an auto-dismiss timer and is untouched, as is the background dispatch toast -- its timer measures "the summary has stopped changing" rather than reading time. Manual dismissal is unchanged for every type. |
||
|
maziggy
|
33ab5f1ead |
Add temperatures to the streaming overlay and a URL builder (#1422)
The overlay at /overlay/{printer} draws live print data over a
full-screen camera view for OBS, a wall display or any browser source.
It has been tunable since it shipped -- which fields, what size, what
frame rate -- but only through query parameters documented in the wiki,
and temperatures were not among the fields on offer. The request asked
for temperatures first and for the field set to be selectable in the web
UI; this addresses both.
Nozzle, bed and chamber readings join the list. The target is drawn only
while the heater is still climbing, so a settled hotend reads "220°C"
for the rest of the print instead of the noisier "220 / 220°C" -- 219.6
against a target of 220 rounds to the same number, and repeating it says
nothing. Both nozzles appear on a dual-nozzle machine. They are drawn
whether or not a print is running, because a preheating printer is
exactly when they are worth watching, and each reading appears only when
the printer genuinely reports one: chamber temperature stays absent on
P1 and A1 models, which publish a chamber_temper with no sensor behind
it, so the overlay never puts a measurement on screen that does not
exist. Labels reuse the heater chart's strings rather than inventing a
second vocabulary for the same three things.
The feed sends an allow-list rather than the temperatures dict. That
dict doubles as the MQTT client's working memory -- derived heater flags
and private target-set timestamps live alongside the readings -- and an
overlay token is a narrower grant than a login, so it gets exactly what
the overlay draws and does not pick up fields as the dict grows. The
same chamber-sensor gate the full status payload already applies is
applied here. The integration test that asserts the payload's exact key
set, which exists to catch that surface widening silently, is updated
deliberately.
Temperatures are not in the default field set, so an overlay URL already
pasted into a scene renders identically after upgrading.
Settings -> API Keys -> Streaming Overlay now builds the URL: printer,
field checkboxes, size, frame rate, camera toggle, an optional token,
and a copy button. It persists nothing and calls nothing new -- the URL
is the configuration, which keeps a scene reproducible by copy-paste and
lets two displays show different fields off one token. Fields are
emitted in the overlay's own top-to-bottom order rather than click
order, and parameters left at their default are omitted, so the same
selection always produces the same URL. The preview alongside it stays
off until asked for: an always-live iframe would hold a subscriber on
the printer's single camera connection for as long as the settings tab
stayed open.
The preview needed one narrow security-header change. Every SPA route
sent frame-ancestors 'none', which is stricter than the SAMEORIGIN in
X-Frame-Options beside it and refuses even a same-origin frame, so the
preview showed Firefox's "another site has embedded it" page instead of
the overlay. The overlay path now sends 'self', mirroring /gcode-viewer,
which admits a framer only on this origin -- Bambuddy's own UI. Every
other path keeps 'none', and embedding the overlay from another host
still requires TRUSTED_FRAME_ORIGINS.
|
||
|
maziggy
|
71a06f3638 |
Add batch orders with a quantity per plate (#342)
Printing a multi-plate file in different quantities per plate meant queueing each plate separately and tracking the counts by hand: one shared Quantity field cannot say "plate 1 once, plate 2 twice, plate 3 three times". Each selected plate now carries its own quantity, and the submission becomes an order on a new Batches tab. The point is the distinction the old flat batch could not express. print_batch_plates stores how many runs of each plate were wanted, separately from what was queued, so a run that fails, is cancelled or is skipped does not satisfy a target -- the order goes on saying it owes a print instead of quietly under-delivering. Queue remaining re-queues exactly what is missing, for the whole order or one plate, by cloning the most recent item for that plate: that inherits the printer or model target, AMS mapping, filament overrides and print options along with the validation they already passed, rather than re-serialising twenty fields through a template that would drift from the model the first time someone adds a column. Clones append to the end of the relevant printer's queue and take the same advisory lock the add-to-queue route does; positions are per-printer sequences, not global. Cost is measured, not estimated. print_log_entries gains queue_item_id, set where the queue item is already in scope, so each run's material and energy are attributed through the item that produced them -- an unrelated reprint of the same archive never lands in an order's total, and a multi-plate order gets each plate's own cost rather than the whole file's via the plate-scoped estimate from #2614. Before any run has completed there is no honest figure, so cost reads as unknown instead of a fabricated 0.00. The Batches tab wires up GET /queue/batches, which has been unreferenced since the batch MVP shipped, along with six locale keys that were translated and never used. It is a separate tab because an order outlives the queue that produced it: once its runs finish they leave the active queue, so Queue and History each hold half the picture. completed was not a reachable status before now, so every batch created since April is still marked active however long ago its last print finished -- 73 of them on the development install. A startup pass closes out the finished ones: those whose runs all completed become completed, and groupings whose items were all cancelled become cancelled, which is what they are. Not applied to orders, which state their intent independently of their runs and still owe the work. Only batches with nothing queued or printing are considered, and repeating the pass also catches an order whose last run landed while the process was down. Batches with neither items nor targets are no longer listed at all -- empty shells left when a grouping's items went with their source archive. Dispatch applies the same source-file gates as POST /queue/. It creates queue items, so without them it would be a weaker door to the same outcome; the archive and library-file checks move into shared helpers so a third route cannot drift from them. |
||
|
maziggy
|
28a6ca6f4d |
Add CAP_NET_BIND_SERVICE everywhere the service is defined (#2549)
The Virtual Printer binds 990 and 322, below 1024, which a service running
as a normal user may not do without CAP_NET_BIND_SERVICE. Without it the
rest of Bambuddy works and only the VP is dead -- sockets never open, the
slicer never finds the printer, and the sole trace is one journal line.
|
||
|
maziggy
|
c28e053126 |
Keep live updates flowing while the tab is in the background (#2754)
Printer status, query invalidations and the message queue all ran their work inside requestAnimationFrame. A hidden tab gets no rendering opportunities, so the browser holds those callbacks instead of merely throttling them: the socket stayed open, messages kept arriving, and every cache write parked in a pending frame until the tab was shown again — at which point they all ran at once. The tab-title progress reads ['printerStatus', id] and nothing else, so it simply froze. The frames came in with the print-completion freeze fix, where the load-bearing part was the coalescing (100ms throttle, 3s debounce, 500ms stagger). That is untouched; the frames only deferred each write by ~16ms and are gone. Not made visibility-aware on purpose — a frame scheduled just before hiding would fire after the writes that took the hidden path and clobber newer status with older. The six rAF stubs in the tests ran frames synchronously, which is why nothing caught this. Replaced with coverage that stubs rAF to never fire, as a hidden tab does. |
||
|
maziggy
|
8dde48587e |
Move the bug-report trigger out of the contended corner (#2750)
The floating disc is pinned bottom-right, which is where most controls live — it covered ~83% of the Profiles scroll-to-top button at the same z-index, and being viewport-fixed it also sits on card action buttons that scroll under it. Below the sidebar-compact breakpoint the trigger moves into the top bar; at 1144px and up nothing changes. Not a hide switch: the bubble is the only entry to the report form, and that form runs the printer diagnostic, the log scan and the debug capture. Hiding it yields reports with nothing attached. The panel stays at the Layout root — the header is a fixed z-40 stacking context and would bury a nested z-50 panel under every modal. Also fixes the panel hanging 16px off-screen on phones: w-full resolves against the viewport, so right-4 pushed its left edge negative. |
||
|
maziggy
|
dbf674561c |
Sort the inventory by colour, not colour name (#2729)
The Color column was missing from the page's sort-extractor map, so its header ignored clicks. Sorts by family first — rainbow, then browns, then neutrals light to dark — with the hue sort running inside each. The issue asked for a straight hue/saturation/lightness sort. Measured against a real 30-spool inventory that puts Titan Gray (hue 210, sat 0.04) among the blues and a warm grey next to the reds, and splits the oranges around brown. Neutrals order by lightness because their hue is noise. Families come from the classifier that already names colours missing from the catalog, so the Color and Color Name columns cannot disagree. |
||
|
maziggy
|
689f5276e4 |
Show the compose directory in the Docker update command (#2664)
The printed command only works from the directory holding the compose file, which is the thing the user came to the page not knowing. Adds a copy button, a saved Compose directory setting, BAMBUDDY_COMPOSE_DIR, and best-effort detection from a bind mount's host path. Compose records the directory on every container it creates, but reading that label needs the Docker socket mounted in — root-equivalent access for a convenience string. The mountinfo guess is a prefill only: its root field is relative to the mounted device, so a compose dir on its own mount loses that prefix, and nothing in the container can detect it. The field is restricted to path characters. It is the one setting whose purpose is to be pasted into a root shell, so "/opt/bambuddy; rm -rf /" would otherwise render as a plausible update command. |
||
|
maziggy
|
a08d3e62f3 |
Show the Print Log's per-run cost and energy, and let users pick columns (#2636)
The list and update endpoints serialised field by field and never named cost / energy_kwh / energy_cost, so values Bambuddy had been recording all along went out as nulls. Both now validate from the ORM row, which removes the chance to omit a field rather than patching the three that were missing. Adds a Filament Used column plus a Columns picker for Cost, Energy, Energy Cost and Finished, persisted per browser. Also fixes the log view being unreachable with zero archives: the empty state ran before the view check, hiding a log that outlives the archives it refers to. --- Sort the Print Log by any column (#2636) Adds sort_by / sort_dir to the print-log endpoint, driven by clickable column headers. Server-side because paging is: ordering the rows the client holds would sort one page rather than the log. Empty values are held last in both directions — Postgres sorts NULLs high and SQLite low, so the same click would otherwise open on blanks on one backend and values on the other. id DESC breaks ties so paging through a low-cardinality sort can't repeat or skip a row. |
||
|
maziggy
|
e95c42c021 |
Add auto-orient and auto-arrange to server-side slicing (#2548)
Both are per-slice checkboxes, off by default, forwarded as the sidecar's orient / arrange form fields. An unticked box is sent by omission: the sidecar treats any present value as truthy, so a literal "false" would have arranged every slice. Arrange unions with the #1493 cross-class decision rather than replacing it, and the per-plate slice-all loop is now keyed on the arrange flag itself — the project-wide collapse belongs to --arrange, not to the cross-class case. The loop also covers the embedded-settings path, whose crash-retry is suppressed there since a single --slice 0 retry would return one consolidated plate. |
||
|
maziggy
|
ea63355fde |
Fix cross-model queue items being misrepresented and editable into a broken state (#671)
The edit dialog offered a printer picker and target-model dropdown for an item with alternatives. Saving left a row with variants AND a printer_id, and the scheduler's fixed-printer branch wins that race, so it dispatched a row whose library_file_id is still null and failed in the upload. PATCH now refuses printer/model changes on such an item — comparing against the current value, since the dialog re-sends target_model unchanged — and the route eager-loads variants, without which the guard could not see them and every PATCH response dropped the alternatives from its payload. Names come from a shared helper now. A cross-model item holds neither archive_id nor library_file_id until dispatch, so five separate inlined fallbacks all rendered "File #null"; they now read "x1c.gcode.3mf +1 more". The queue also grouped these under "Any H2D" — the first candidate mirrored onto the row — filing a job under a printer it might never run on. It groups as "Any H2D / X1C", matching the row beneath it. |
||
|
maziggy
|
ef7c1b21f1 |
Add cross-model print alternatives to the File Manager and print modal (#671, #2570)
Selecting several sliced files and pressing Print now creates one queue item carrying all of them, instead of hiding the Print button the moment a second file is selected. The printer picker is replaced by the ordered candidate list, since choosing these files is already the answer to "which printer" and the only question left is which is preferred. Per-candidate configuration is the plate only. Model-based assignment sends no AMS mapping — the printer is unknown until dispatch, where the scheduler derives it — so a per-candidate mapping editor would collect choices it then discards. Filament overrides stay shared: "this job needs PETG" holds for every slice of the same job. Adds Group as versions for durable grouping, a versions badge counting the whole group rather than the rows on screen, and a queue card label naming every model a pending item is waiting on. |
||
|
maziggy
|
da07c5884b |
Add variant-group data model for cross-model queue alternatives (#671)
Adds file_variant_groups plus variant_group_id / variant_position on library_files, so a set of files that are the same job sliced for different printers can be resolved to whichever printer frees up first. Backfills groups from the sliced_from_library_file_id provenance that slice_and_persist and the pipeline runner have been writing into file_metadata since they shipped, and which nothing has ever read. Only sources with two or more children carrying distinct sliced_for_model values are grouped: a single candidate is not a choice, and two slices for the same printer give the resolver no basis to prefer one. |
||
|
maziggy
|
b04664c64a |
Raise the chamber-temperature ceiling from 60 to 65 C
Every field that takes a chamber target stopped at 60: the per-filament chamber map and per-print override in Preheat & Heat Soak, the chamber quick-select presets, and the printer-card chamber control. 60 is the X1E's ceiling and the X1E was the only heated-chamber model when that limit was written; the H2 series and X2D heat to 65, so the top of their range was unreachable. The ceiling now lives in one constant per side (MAX_CHAMBER_TEMP_C in backend/app/utils/printer_models.py and frontend/src/utils/printer.ts) rather than as a literal at each call site. X1E firmware clamps a higher request to its own maximum, so a shared ceiling is safe. Also fixes a live bug at PrintersPage.tsx:7985: parsePresetTriple was bounded to 60 there, and it rejects the whole triple on any out-of-range entry, so a saved 65 preset would have silently reverted the printer card to the defaults while Settings still showed 65. |
||
|
maziggy
|
30daed2756 |
Fix per-job queue ETA showing for jobs that cannot start now
The scheduler only writes waiting_reason on the model-based assignment path, so a job pinned to a specific printer sits behind a running print with no marker at all. Every such job rendered an identical "starts now" ETA that was wrong by the length of everything ahead of it. Decide eligibility on the page instead: an item gets an ETA only when its printer is idle and it is the item the scheduler would dispatch next, following the same ordering the scheduler uses. Staged and future- scheduled items do not block the item behind them, matching the scheduler, and items conditional on a previous print are excluded. The value also froze at first render, since react-query's structural sharing keeps the queue reference stable and nothing re-rendered the row. formatETA now accepts a base instant and the page drives it from a 30s clock shared by every visible row. Retire the borrowed printers.estimatedCompletion tooltip for a queue key that says what the number means, translated into all 13 locales. |
||
|
maziggy
|
aef4f3a3e9 |
fix(oidc): strip the required BAMBUDDY_OIDC_* values and register the local-login bypass
A Kubernetes Secret written as a block scalar carries a trailing newline, and the schema bounds the four required variables by max_length only, so an unstripped issuer_url was stored and enabled and then raised httpx.InvalidURL on the first click of the SSO button -- the authorize-time failure the all-or-nothing rule exists to prevent. Whitespace-only values got through the same way, contradicting the reader's own "an empty required var counts as unset". The optional variables have always treated blank as unset; the required ones now do too. Also registers BAMBUDDY_LOCAL_LOGIN (#1589) in the typo guard, which logged "possible typo" for it on every boot while listing every BAMBUDDY_OIDC_* variable as legitimate. |
||
|
maziggy
|
43cb216ae9 |
fix(settings): stop the Settings page reverting changes made elsewhere (issue #2716)
While the Settings page was mounted it held its own copy of every setting and synced it from the server exactly once, on first load (:887-900). A debounced effect then diffed the live ['settings'] cache against that copy and PUT all 77 keys it manages on any difference, with no way to tell a user edit from a value that had changed on the server. Anything written server-side while the page sat open was silently reverted ~500ms later (#2716, reporter @jmoore-skild). No interaction was needed to trigger it. The query inherits a 60s staleTime and react-query's default refetchOnWindowFocus, and ~30 other observers share the key, so a window refocus or a refetch from any of them moved the cache and the page wrote its page-load snapshot back over all 77 keys -- showing "Settings saved" while doing it. The page now tracks the last server snapshot it reconciled with. A field still equal to that baseline has not been touched since, so a newer server value is adopted; a field the user has edited keeps their value and is saved over the top, so the newer of the two writes wins either way. Typing into a text field while a refetch lands stays safe, which is what the previous behaviour was protecting -- an in-progress edit is by definition different from the baseline. The baseline is seeded from the raw server row rather than from the copy the page patches a browser-detected external_url into, so that detection still reads as a local change and is still persisted. The payload builder and the comparison key lists are unchanged. The diff simply measures against the baseline instead of the live cache, so no field can silently stop saving. Removing the adoption step was verified to reintroduce the revert, and removing the post-save baseline advance to reintroduce a resend loop; both are covered by frontend tests asserting on the request bodies rather than on rendered values. |
||
|
maziggy
|
18938a10ee |
fix(kprofiles): stop reporting rejected K-profile writes as saved
Saving a K-profile was fire-and-forget. set_kprofiles_batch published and returned True, and the printer's extrusion_cali_set answer was logged at DEBUG and dropped, so a write the printer refused was reported to the user as saved (#2718, reporter @jmoore-skild). The reason it could not simply be gated on: the answer itself was wrong. Single-nozzle firmware returned result:"fail" with reason:"invalid tray_id" on writes that demonstrably applied. Measured against an X1C and an H2D over MQTT, the cause is the tray_id:-1 Bambuddy itself put in the payload. Sending three otherwise identical writes isolated it: tray_id:-1 fails, tray_id:0 succeeds, and cali_idx:-1 is accepted either way, so only that one field is at fault. The H2D ignores the value entirely; the X1C validates it, complains, and applies the write anyway. BambuStudio always sends a real tray_id and defaults it to 0 for a manually entered profile. With tray_id:0 the acknowledgement is honest, and the printer echoes back the sequence_id we sent -- confirmed for extrusion_cali_get, _set and _del on both printer classes -- so it can be matched to the write that caused it. Writes now return their sequence_id and the routes await the verdict, turning a real failure into an error that carries the printer's own reason. A printer that stays silent is still treated as success: no answer is not evidence of refusal, and firmware that never answers must not turn every save into an error. Raises the ack to INFO. It sat at DEBUG, so the one line that explains a failed save was absent from every support bundle -- the same reasoning that put ams_filament_drying at INFO for #1447. Also fixes extrusion_cali_set building its payload from str(self._sequence_id) without incrementing first, reusing the previous command's id. Harmless while nothing correlated on it, fatal now that the write path does. Adds supports_nozzle_flow_type() for the Standard / High Flow choice, which the K-Profiles UI previously showed as "Not reported by printer" -- not a value anyone can save. Most printers omit the nozzle identity from their calibration table entirely, and the slicer treats that as Standard rather than unknown; Bambuddy now does the same and keeps the choice editable. The field is hidden only where the model ships a single nozzle variant, using the slicer's own rule (len(nozzle_volume) // len(nozzle_diameter) > 1 over the machine preset) evaluated across every bundled Bambu profile. That puts only A1, A1 Mini and A2L on the hidden side -- it is not the single- versus-dual-nozzle split, since P1P, P1S, P2S, X1, X1C, X1E and H2S are all single-nozzle and all carry two variants. Editing a profile also no longer writes back an empty nozzle_id. Wiki records that on printers which omit the field the chosen flow type is discarded by the firmware and reads back as Standard, in Bambu Studio as well, so it does not get filed as a bug again. |
||
|
maziggy
|
af282b3527 |
fix(kprofiles): populate the filament picker from all preset tiers (issue #2719)
Add K-Profile built its Filament dropdown from the profiles already on the printer, so on a printer with none the field was empty, required and unsatisfiable (#2719, reporter @jmoore-skild). The modal's own hint described the dead end: create the profile in Bambu Studio first. The dropdown now uses the app-wide lookup order -- local imported, Orca Cloud, Bambu Cloud, hardcoded built-in table -- same as the AMS slot picker and the SliceModal tier groups. The built-in table is compiled into the backend, so the list can never be empty: a new printer with no cloud account and nothing imported still gets a first profile. Not fixed the way the report suggested. Seeding from /printers/available-filaments would have offered only what happens to be in an AMS right now, which on the reported printer is nothing; its tray_info_idx is empty or a cloud user preset rather than a filament id; it aggregates across every printer of the same model; and it is gated on QUEUE_CREATE, which the K-Profiles page does not hold. The printer indexes its calibration table by filament_id, so the picked preset is reduced to one before anything is sent. Built-in entries and Bambu official cloud presets carry one; a cloud user preset needs its detail fetched (never base_id -- that collapses a custom preset onto its inherited generic, #1053); imported and Orca presets have no Bambu id at all and take the closest generic for their material, via the same table the AMS slot configure flow uses so the two agree. A filament that resolves to nothing is refused with a named error rather than written under a wrong id. Collapses duplicates from two separate causes. A cloud account carries one copy of each filament per printer model, and with the "@BBL <model>" suffix stripped for display those rows are indistinguishable -- deduped within each tier by resolved filament id, by display name for user presets that have none. Cloud setting_ids also carry a "_NN" variant suffix, so the built-in tier's already-covered check never matched and listed the same filament again; the bare id is now recorded alongside. Groups the options by source with an optgroup per tier, styled in index.css: browsers render optgroup labels small, grey and italic, which buries the one thing distinguishing a "Bambu PLA Basic" you imported from the one the built-in table ships. Drops the second getKProfiles(printer, "0.4") query that existed only to seed the old dropdown. It ran concurrently with the main fetch whenever a non-0.4mm nozzle was selected -- the two-requests-in-flight case that made K-profile fetches time out. --- fix(ui): cancel a dialog's deferred close when it unmounts The AMS slot configure and K-Profile dialogs hold a success state briefly and then close themselves -- 1.5s to 4s after the command goes out, so the printer has time to process it before the list refetches. Each did that with a bare setTimeout closing over setState and the parent's onClose, and nothing cancelled it. The timer therefore ran whether or not the dialog was still there. Dismissing it inside that window, or the printer card re-rendering underneath it, left a pending close that fired later and dismissed whatever dialog was open by then. It also threw outright when the surrounding environment was gone first: a test tearing down its DOM before the 1.5s elapsed produced "ReferenceError: window is not defined" out of react-dom's resolveUpdatePriority, reported as an unhandled error against a suite that otherwise passed. Routes all five through a useCancellableTimeout hook -- two in ConfigureAmsSlotModal, three in KProfileModal, the latter with the longest windows and so the widest exposure. Scheduling replaces any pending timer and unmounting clears it. |
||
|
maziggy
|
a35ba8fa5f |
fix(kprofiles): read the nozzle diameter the printer actually sent (issue #1748)
Every K-profile came back as 0.4mm on printers running any other nozzle (#1748, reporters @Liquidmasl and @jmoore-skild). The printer puts nozzle_diameter on the extrusion_cali_get envelope only; the per-filament entries carry setting_id, filament_id, name, k_value, n_coef and cali_idx, and nothing else. The parser read the field per entry with a hardcoded "0.4" fallback, so the fallback fired on every profile of every response. The envelope value was already in scope, read into response_nozzle and used only to match the request. This never reproduced on H2D because that firmware does include the field per entry. Both construction sites are in the same handler, so the code path is shared; what differs is the payload, and every single-nozzle model omits it. The display was the least of it. Editing is delete-and-re-add on single-nozzle printers, and the dialog rebuilt nozzle_id and nozzle_diameter from its own greyed-out selects, so saving an untouched 0.6mm profile rewrote it on the printer as HH00-0.4. Deleting aimed extrusion_cali_del at the wrong nozzle the same way. Both now pass through what the printer reported. The cali_idx cascade in inventory.py, spoolman_inventory.py and spoolman.py matches on nozzle_diameter, so on a 0.6 or 0.8 nozzle it never found the printer-side entry and the assignment silently failed to stick -- that is the "cannot auto-map a K-profile" half of the report, fixed at the source without touching those three call sites. nozzle_id has no source in the payload at all, and state.nozzles carries material (hardened_steel), not flow, so it cannot honestly produce HH/HS. Rather than keep inventing one, the UI now says the printer did not report it: the card shows the diameter alone, the dialog shows "Not reported by printer", and the High Flow / Standard filter is hidden instead of being offered as a control that can only ever empty the list. Import stops stamping HH00 on profiles whose source reported none. Also correlates K-profile requests by sequence_id. Responses were matched by nozzle diameter through a single shared expectation slot, so a second request overwrote the first's and the first's valid answer was discarded as a mismatch -- the "Failed to get K-profiles after 3 attempts" in the same logs, with the printer having answered correctly both times. Pending state is now one entry per request, keyed by the id we already send, with the nozzle match kept as a fallback for firmware that does not echo it back. Fixes the flow-type select naming a new profile with the opposite label, which contradicted the identical expression 44 lines above it. |