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 #1134] [Bug]: background-dispatch watchdog only logs on non-transition; queue/UI still see "started successfully" #814

New issue

Closed

opened 2026-05-07 00:14:01 +02:00 by BreizhHardware · 1 comment

BreizhHardware commented

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

Owner

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

Originally assigned to: @maziggy on GitHub.

Component

Bambuddy

Bug Description

When a print is sent via the background-dispatch path and the printer
never transitions out of its prior state (because of a half-broken MQTT
session, lingering FAILED/HMS state, no SD card, etc.), Bambuddy logs the
publish as Print started successfully, marks the archive as printing,
and never rolls that back. The watchdog _verify_print_response
(backend/app/services/background_dispatch.py:897) does detect the
non-transition — it logs a WARNING and force-reconnects the MQTT session
— but it is fire-and-forget and never touches the queue/archive/WS layer.

The queue path already handles this correctly: _watchdog_print_start
in backend/app/services/print_scheduler.py:1955 reverts the queue item
to pending after timeout (#967, #1078) and force-reconnects MQTT. The
background path needs the same treatment, or a shared implementation.

Evidence from the new support pack on #1042 (P1S sitting in
gcode_state: FAILED + HMS 0300_400C "task was canceled"):

18:02:03.591 PRINT COMMAND: printer=3, ... caller=background_dispatch.py:539:_process_job
18:02:03.592 Sending print command: ... task_id: 1167547522
(UI/archive marked successful)
18:02:18.596 WARNING [background_dispatch] Printer (3) did not respond
to print command within 15s (state still FINISH)
18:02:18.597 WARNING [bambu_mqtt] Forcing MQTT reconnect: ...
(no state change to UI/archive)

Expected Behavior

When _verify_print_response times out:

Mark the originating archive/job as failed (or revert to its prior
state) so the UI doesn't show a successful dispatch.
Emit a printer_status / archive_updated WebSocket update so the
frontend reflects it without polling.
Keep the existing force_reconnect_stale_session recovery.

Two related observations while we're in there:

The queue watchdog also accepts subtask_id advancing past
pre_subtask_id as a definitive "command landed" signal (see #1078 —
H2D can sit at FINISH for ~50 s after accepting project_file).
_verify_print_response doesn't use this and could false-warn on slow
H2D transitions; should mirror the queue logic.
Consider extracting both watchdogs into a single helper so future
fixes only land in one place.

Steps to Reproduce

Put a P1S into FAILED/cancelled state (HMS code present, e.g.
0300_400C).
Trigger a non-queue print (background dispatch — direct dispatch from
the printer card, etc.).
Observe: UI shows print started successfully; the printer never
transitions; only a backend WARNING is logged 15 s later.

Printer Model

None

Bambuddy Version

all

SpoolBuddy Version

No response

Printer Firmware Version

No response

Installation Method

Manual (git clone)

Operating System

Linux (Ubuntu/Debian)

Relevant Logs / Support Package

Follow-up to #1042 — the int32 task_id fix landed in 0.2.3.2 is verified
working in the most recent support pack on that thread; this issue
captures the second item from the original report ("Don't treat
project_file result=success as dispatch success").

Code references:

backend/app/services/background_dispatch.py:897 — _verify_print_response
backend/app/services/print_scheduler.py:1955 — _watchdog_print_start (model to copy)
backend/app/services/print_scheduler.py:1844 — clearer of the
awaiting_plate_clear flag during retry, also relevant to UI sync

Screenshots

No response

Additional Context

No response

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 @maziggy on GitHub (Apr 26, 2026). Original GitHub issue: https://github.com/maziggy/bambuddy/issues/1134 Originally assigned to: @maziggy on GitHub. ### Component Bambuddy ### Bug Description When a print is sent via the **background-dispatch path** and the printer never transitions out of its prior state (because of a half-broken MQTT session, lingering FAILED/HMS state, no SD card, etc.), Bambuddy logs the publish as `Print started successfully`, marks the archive as printing, and never rolls that back. The watchdog `_verify_print_response` (`backend/app/services/background_dispatch.py:897`) does detect the non-transition — it logs a WARNING and force-reconnects the MQTT session — but it is fire-and-forget and never touches the queue/archive/WS layer. The **queue path** already handles this correctly: `_watchdog_print_start` in `backend/app/services/print_scheduler.py:1955` reverts the queue item to `pending` after timeout (#967, #1078) and force-reconnects MQTT. The background path needs the same treatment, or a shared implementation. Evidence from the new support pack on #1042 (P1S sitting in `gcode_state: FAILED` + HMS `0300_400C` "task was canceled"): 18:02:03.591 PRINT COMMAND: printer=3, ... caller=background_dispatch.py:539:_process_job 18:02:03.592 Sending print command: ... task_id: 1167547522 (UI/archive marked successful) 18:02:18.596 WARNING [background_dispatch] Printer (3) did not respond to print command within 15s (state still FINISH) 18:02:18.597 WARNING [bambu_mqtt] Forcing MQTT reconnect: ... (no state change to UI/archive) ### Expected Behavior When `_verify_print_response` times out: - Mark the originating archive/job as failed (or revert to its prior state) so the UI doesn't show a successful dispatch. - Emit a `printer_status` / `archive_updated` WebSocket update so the frontend reflects it without polling. - Keep the existing `force_reconnect_stale_session` recovery. Two related observations while we're in there: - The queue watchdog also accepts `subtask_id` advancing past `pre_subtask_id` as a definitive "command landed" signal (see #1078 — H2D can sit at FINISH for ~50 s after accepting `project_file`). `_verify_print_response` doesn't use this and could false-warn on slow H2D transitions; should mirror the queue logic. - Consider extracting both watchdogs into a single helper so future fixes only land in one place. ### Steps to Reproduce 1. Put a P1S into FAILED/cancelled state (HMS code present, e.g. `0300_400C`). 2. Trigger a non-queue print (background dispatch — direct dispatch from the printer card, etc.). 3. Observe: UI shows print started successfully; the printer never transitions; only a backend WARNING is logged 15 s later. ### Printer Model None ### Bambuddy Version all ### SpoolBuddy Version _No response_ ### Printer Firmware Version _No response_ ### Installation Method Manual (git clone) ### Operating System Linux (Ubuntu/Debian) ### Relevant Logs / Support Package Follow-up to #1042 — the int32 task_id fix landed in `0.2.3.2` is verified working in the most recent support pack on that thread; this issue captures the second item from the original report ("Don't treat project_file result=success as dispatch success"). Code references: - `backend/app/services/background_dispatch.py:897` — `_verify_print_response` - `backend/app/services/print_scheduler.py:1955` — `_watchdog_print_start` (model to copy) - `backend/app/services/print_scheduler.py:1844` — clearer of the `awaiting_plate_clear` flag during retry, also relevant to UI sync ### Screenshots _No response_ ### Additional Context _No response_ ### 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:14:01 +02:00

closed this issue
added the
bug
label

BreizhHardware commented

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

Author

Owner

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

Available/Fixed in branch dev and available with the next release or daily build.

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): Available/Fixed in branch dev and available with the next release or daily build. ----- If you find Bambuddy useful, please consider giving it a ⭐ on [GitHub](https://github.com/maziggy/bambuddy) — it helps others discover the project!

BreizhHardware referenced this issue

2026-05-07 00:16:08 +02:00

[PR #814] [MERGED] Spoolbuddy init and diagnostic improvements #1122

BreizhHardware referenced this issue

2026-05-07 00:16:10 +02:00

[PR #830] [MERGED] v0.2.2.2 #1129

BreizhHardware referenced this issue

2026-05-07 00:16:21 +02:00

[PR #1029] [MERGED] v0.2.3 final #1155