maziggy d7093c7fe4 fix(dispatch): don't send start-print to a busy printer; scheduler defers (#2598) ...

start_print() published project_file guarding only on connection state, so a
re-dispatch onto a printer that had already started — e.g. a watchdog revert
(#2555) after the printer sat in FINISH past accepting the job — collided with
the live print. The firmware answers 0500_4004 ("Device is busy and cannot
start a new task"), which on an A1 mini cancels the running job.

Defense-in-depth at the paths that can reach a busy printer:

- bambu_mqtt: refuse to publish project_file when gcode_state is
  PREPARE/SLICING/RUNNING/PAUSE and return without sending. This is the one
  publish choke point every dispatch path funnels through (queue scheduler,
  manual start, webhook, Virtual-Printer forward). IDLE/FINISH/FAILED still
  start.
- print_scheduler: re-check the live printer state right before the FTP upload
  and defer a busy printer (leave the item pending for a later tick) instead of
  uploading and dispatching. If the printer goes busy in the upload window and
  the start is refused, revert the item to pending rather than marking it
  failed — a busy printer is a deferral, not a failure.

A transport-level MQTT QoS-1 replay on reconnect would bypass the client guard,
but the dispatch/watchdog reconnect path already hard-resets the client with a
fresh session, so it has no inflight project_file to replay.

2026-07-18 16:41:15 +02:00

..

app

fix(dispatch): don't send start-print to a busy printer; scheduler defers (#2598)

2026-07-18 16:41:15 +02:00

tests

fix(dispatch): don't send start-print to a busy printer; scheduler defers (#2598)

2026-07-18 16:41:15 +02:00

__init__.py

…