starred/bambuddy-maziggy-1

Fork 0

mirror of https://github.com/maziggy/bambuddy.git synced 2026-05-09 08:25:54 +02:00

[GH-ISSUE #1128] [Bug]: Plate-clear button stays visible when API clears awaiting_plate_clear without a status update #808

New issue

Closed

opened 2026-05-07 00:13:59 +02:00 by BreizhHardware · 1 comment

BreizhHardware commented

2026-05-07 00:13:59 +02:00

Owner

Originally created by @EdwardChamberlain on GitHub (Apr 25, 2026).
Original GitHub issue: https://github.com/maziggy/bambuddy/issues/1128

Originally assigned to: @maziggy on GitHub.

Component

Bambuddy

Bug Description

Clearing the plate-clear flag via the API does not reliably update the UI, so the “Mark plate as cleared” button and status pill can remain visible after the backend has already cleared awaiting_plate_clear.

commit 4e86e8c fixed the delayed appearance of the plate-clear button by including awaiting_plate_clear in printer status payloads. However, the reverse transition still has a gap: when POST /printers/{id}/clear-plate clears the flag, the backend updates PrinterManager / DB state but does not emit a printer_status WebSocket update and does not return the updated printer status.

The printer does not change physical/MQTT state when this flag is cleared, because awaiting_plate_clear is a Bambuddy state. Therefore the normal MQTT-driven printer_status flow is not triggered. The only reason the button disappears immediately when clicked from the printer card is that the frontend performs an optimistic local React Query cache update. If the flag is cleared through another API caller or route path, that optimistic frontend update does not happen and the UI can remain stale.

The root cause is that set_awaiting_plate_clear() changes state without notifying status subscribers.

Expected Behavior

Any backend change to awaiting_plate_clear should be reflected in the UI immediately and consistently.

When POST /printers/{id}/clear-plate succeeds, Bambuddy should either:

broadcast an updated printer_status WebSocket payload for that printer, including awaiting_plate_clear: false, or
return the updated printer status and have all API callers update/invalidate consistently

Steps to Reproduce

Have a printer in a finished/failed state with awaiting_plate_clear: true.
Open the Printers page and observe the plate-clear button is visible.
Clear the flag via the API route, for example POST /api/v1/printers/{id}/clear-plate, from outside the printer-card button flow.
The backend has cleared awaiting_plate_clear.
The UI may still show the plate-clear button because no printer-status WebSocket update was emitted for the local state change.

Printer Model

None

Bambuddy Version

v0.2.3.2 + dev branch

SpoolBuddy Version

No response

Printer Firmware Version

No response

Installation Method

Manual (git clone)

Operating System

macOS

Relevant Logs / Support Package

No response

Screenshots

No response

Additional Context

github.com/maziggy/bambuddy@e1b4257953/backend/app/api/routes/printers.py (L2360)

Probably wants to emit a state update via ws_manager.send_printer_status() or similar?

Checklist

I have searched existing issues to ensure this bug hasn't already been reported
I am using the latest version of Bambuddy
My printer is set to LAN Only mode
My printer has Developer Mode enabled

Originally created by @EdwardChamberlain on GitHub (Apr 25, 2026). Original GitHub issue: https://github.com/maziggy/bambuddy/issues/1128 Originally assigned to: @maziggy on GitHub. ### Component Bambuddy ### Bug Description Clearing the plate-clear flag via the API does not reliably update the UI, so the “Mark plate as cleared” button and status pill can remain visible after the backend has already cleared awaiting_plate_clear. commit 4e86e8c fixed the delayed appearance of the plate-clear button by including awaiting_plate_clear in printer status payloads. However, the reverse transition still has a gap: when POST /printers/{id}/clear-plate clears the flag, the backend updates PrinterManager / DB state but does not emit a printer_status WebSocket update and does not return the updated printer status. The printer does not change physical/MQTT state when this flag is cleared, because awaiting_plate_clear is a Bambuddy state. Therefore the normal MQTT-driven printer_status flow is not triggered. The only reason the button disappears immediately when clicked from the printer card is that the frontend performs an optimistic local React Query cache update. If the flag is cleared through another API caller or route path, that optimistic frontend update does not happen and the UI can remain stale. The root cause is that set_awaiting_plate_clear() changes state without notifying status subscribers. ### Expected Behavior Any backend change to awaiting_plate_clear should be reflected in the UI immediately and consistently. When POST /printers/{id}/clear-plate succeeds, Bambuddy should either: broadcast an updated printer_status WebSocket payload for that printer, including awaiting_plate_clear: false, or return the updated printer status and have all API callers update/invalidate consistently ### Steps to Reproduce Have a printer in a finished/failed state with awaiting_plate_clear: true. Open the Printers page and observe the plate-clear button is visible. Clear the flag via the API route, for example POST /api/v1/printers/{id}/clear-plate, from outside the printer-card button flow. The backend has cleared awaiting_plate_clear. The UI may still show the plate-clear button because no printer-status WebSocket update was emitted for the local state change. ### Printer Model None ### Bambuddy Version v0.2.3.2 + dev branch ### SpoolBuddy Version _No response_ ### Printer Firmware Version _No response_ ### Installation Method Manual (git clone) ### Operating System macOS ### Relevant Logs / Support Package _No response_ ### Screenshots _No response_ ### Additional Context https://github.com/maziggy/bambuddy/blob/e1b42579531ae402ebc1426ac69c26fd56596c23/backend/app/api/routes/printers.py#L2360 Probably wants to emit a state update via `ws_manager.send_printer_status()` or similar? ### Checklist - [x] I have searched existing issues to ensure this bug hasn't already been reported - [x] I am using the latest version of Bambuddy - [x] My printer is set to LAN Only mode - [x] My printer has Developer Mode enabled

BreizhHardware

2026-05-07 00:13:59 +02:00

closed this issue
added the
bug
label

BreizhHardware commented

2026-05-07 00:14:00 +02:00

Author

Owner

@maziggy commented on GitHub (Apr 26, 2026):

Spot-on diagnosis — your line-level pointer at routes/printers.py:2360 and the suggested 'ws_manager.send_printer_status()` fix were exactly right.

Landed the fix one layer up from your suggestion: rather than emit the broadcast from the route handler, I put it inside
PrinterManager.set_awaiting_plate_clear itself. Reasoning: the same flag gets toggled from at least three other places (on_print_complete, the scheduler at print_scheduler.py:1844 when dispatching the next queued print, and any future caller), and centralising means every current and future caller is covered without remembering to wire it up. The route
handler now just calls set_awaiting_plate_clear(False) and the broadcast piggybacks on the same _schedule_async path the existing DB persistence lready uses.

A few corollary cleanups in the same change:

Broadcast lazy-imports ws_manager to keep printer_manager.py clean
of application-layer infra at module-import time.
Short-circuits when get_status returns None (printer disconnected —
the next reconnect produces a fresh push anyway, no point forcing a
stale snapshot onto subscribers now).
Swallows ws_manager.send_printer_status failures with a WARNING so
the DB persistence coroutine completes even if the WS layer is
temporarily unavailable. The flag is correctness; the broadcast is a
courtesy.
Same hook is now in place for any other Bambuddy-side flag that gets
added to printer_state_to_dict later — they'll all need to broadcast
their own changes for the same reason awaiting_plate_clear did.

Thanks for the analysis — having the root cause stated as "set_awaiting_plate_clear() changes state without notifying status subscribers" made this a one-shot fix rather than a hunt.

Available/Fixed in branch dev and available with the next release or daily build. Please let me know if it works for you.

If you find Bambuddy useful, please consider giving it a ⭐ on GitHub — it helps others discover the project!

@maziggy commented on GitHub (Apr 26, 2026): Spot-on diagnosis — your line-level pointer at `routes/printers.py:2360` and the suggested 'ws_manager.send_printer_status()` fix were exactly right. Landed the fix one layer up from your suggestion: rather than emit the broadcast from the route handler, I put it inside `PrinterManager.set_awaiting_plate_clear` itself. Reasoning: the same flag gets toggled from at least three other places (`on_print_complete`, the scheduler at `print_scheduler.py:1844` when dispatching the next queued print, and any future caller), and centralising means every current and future caller is covered without remembering to wire it up. The route handler now just calls `set_awaiting_plate_clear(False)` and the broadcast piggybacks on the same `_schedule_async` path the existing DB persistence lready uses. A few corollary cleanups in the same change: - Broadcast lazy-imports `ws_manager` to keep `printer_manager.py` clean of application-layer infra at module-import time. - Short-circuits when `get_status` returns `None` (printer disconnected — the next reconnect produces a fresh push anyway, no point forcing a stale snapshot onto subscribers now). - Swallows `ws_manager.send_printer_status` failures with a `WARNING` so the DB persistence coroutine completes even if the WS layer is temporarily unavailable. The flag is correctness; the broadcast is a courtesy. - Same hook is now in place for any other Bambuddy-side flag that gets added to `printer_state_to_dict` later — they'll all need to broadcast their own changes for the same reason `awaiting_plate_clear` did. Thanks for the analysis — having the root cause stated as "set_awaiting_plate_clear() changes state without notifying status subscribers" made this a one-shot fix rather than a hunt. Available/Fixed in branch dev and available with the next release or daily build. Please let me know if it works for you. ----- If you find Bambuddy useful, please consider giving it a ⭐ on [GitHub](https://github.com/maziggy/bambuddy) — it helps others discover the project!