_watchdog_print_start now treats subtask_id-advance as Phase A
"command landed", not as final success. Phase B (180s) keeps watching
for the active-state transition; if it never arrives — printer
accepted the file but stalled (cloud+LAN re-auth after a power cycle
on old firmware was the reported trigger) — revert the queue item to
'pending' instead of leaving it stuck in 'printing' until container
restart. Phase B skips force_reconnect because subtask_id-advance
proves the project_file landed; a reconnect mid-parse would trigger
0500_4003 (#1150). Phase A's H2D 50s FINISH→PREPARE tolerance (#1078)
is preserved by Phase B's 180s headroom.
Both the queue-side _watchdog_print_start and the direct-dispatch
_verify_print_response used `status.state != pre_state` to decide
whether a project_file command had been accepted. When a printer was
in FINISH at dispatch time (un-dismissed post-print prompt from a
prior job), the firmware silently rejected the new command; if the
user then dismissed the screen prompt, the printer moved FINISH ->
IDLE and the watchdog returned early as "command landed" — leaving
the queue row stuck at status='printing' indefinitely and the
scheduler permanently marking the printer as busy.
Narrow the "command landed" check in both verifiers to an allow-list
of active-print states (PREPARE / SLICING / RUNNING / PAUSE).
Inactive transitions (FINISH -> IDLE, etc.) no longer short-circuit
the revert. The subtask_id-advance signal stays in place for H2D's
slow FINISH -> PREPARE transition (#1078).
Also wrap _watchdog_print_start's revert commit and
printer_manager._persist_awaiting_plate_clear in run_with_retry so
SQLite single-writer contention can't silently drop these writes.
The revert path returns a tristate sentinel so the post-revert MQTT
session-recovery logic only runs when we actually reverted (or the
commit failed) — not when on_print_complete had already cleared the
row, where a forced reconnect could break a healthy concurrent print.
Background: P1P firmware can take ~135 s after a project_file MQTT publish
to actually start parsing the uploaded .3mf — gcode_state stays IDLE and
subtask_id doesn't advance until parse completes. The dispatch watchdogs
treated the missed transition as a #887/#936 half-broken session and called
force_reconnect_stale_session, which interrupts the printer's in-progress
parse and triggers 0500_4003 ("can't parse print file") on the printer side.
Both #1150 (slow parse) and #887/#936 (zombie session) look identical from
state and subtask_id alone — both have stale state and stale subtask_id with
fresh telemetry. The distinguishing signal is the printer's gcode_file
field: it updates in push_status when the project_file command actually
lands on the printer, but stays unchanged when the publish was silently
swallowed.
Both watchdogs (_verify_print_response in background_dispatch and
_watchdog_print_start in print_scheduler) now capture pre_gcode_file from
printer_manager.get_status() before sending the publish, then on timeout
compare it against the last good status seen during the poll loop. If the
file changed, the command landed → log a #1150 warning, skip the forced
reconnect to avoid 0500_4003 mid-parse. If unchanged, fall through to the
original force_reconnect_stale_session call so the half-broken-session
recovery is preserved exactly.
Caveat documented in code: in a retry-same-file slow-parse scenario the
gcode_file looks identical pre/post-publish, so the watchdog falls through
to the reconnect path and the user still hits 0500_4003 on that retry.
Accepted to avoid breaking the half-broken-session recovery, which is the
more impactful regression of the two.
The new pre_gcode_file kwarg has a default of None on both watchdog
functions, so any caller that doesn't pass it keeps the original
reconnect-on-timeout behavior verbatim.
4 new unit tests cover both watchdogs: skip on gcode_file change (#1150
fix), reconnect when unchanged (#936 protection preserved), skip when
pre=None and current is non-None (printer just connected), reconnect when
pre_gcode_file arg is omitted (backward-compat). All 439 existing
dispatch / scheduler / mqtt tests pass unchanged.
_watchdog_print_start reverted queue items to "pending" at 45 s if
gcode_state hadn't changed, assuming the MQTT project_file was swallowed
by a half-broken session (#887/#967). H2D Pro firmware (01.01.00.00)
routinely keeps state=FINISH for 48-55 s after actually accepting the
command before transitioning to PREPARE. The watchdog reverted items
the printer had already started physically printing; the archive updated
normally via _active_prints, but the queue item was now "pending" again,
and the next scheduler tick after plate-clear re-dispatched the same
item as if it had never run. With one item left in the queue that looked
like a reprint of the just-finished job; with multiple items the
symptom was masked by item N+1 getting dispatched during the race.
Add a second "command landed" signal: subtask_id advancing past the
pre-dispatch value. Bambuddy already mints a unique submission_id per
project_file publish (#1042) and the printer echoes it back on the next
push_status as soon as it starts processing the command - well before
gcode_state transitions on slow-transition models. _start_print now
captures pre_subtask_id alongside pre_state and passes both to the
watchdog, which exits early on either a state change or a subtask_id
advance.
Raise default timeout 45 s → 90 s as belt-and-braces for printers that
neither flip state nor echo subtask_id inside the polling window.
Genuinely half-broken sessions (both signals unchanged across the full
90 s) still revert + force-reconnect exactly as before.
Transient subtask_id=None during reconnect is not mis-detected as a
change. pre_subtask_id=None falls back to state-only checking so the
fix is safe for printers that haven't reported a subtask_id yet.
New test_scheduler_watchdog.py pins the eight behaviours that matter:
pickup via state change; pickup via subtask_id change with state still
FINISH (the exact #1078 case); revert when neither signal changes;
default timeout is 90 s; pre_subtask_id=None state-only fallback;
current subtask_id=None not treated as change; printer disconnect
mid-watchdog leaves DB untouched; item that already moved on is not
clobbered.
maziggy