Bambuddy's VP supports two slicer flows: Send (file upload only — what
queue/immediate/review modes are designed for) and Print (file upload
+ start-print, intended for proxy mode). When a user clicks Print
against a non-proxy mode the VP must still respond gracefully — the
file is fine to receive, just the start-print never happens. Instead
the slicer wedged at "Downloading...(0%)" and blocked the next
dispatch with "The printer is busy with another print job".
Cause: on_file_received transitioned gcode_state PREPARE -> IDLE
directly. Print-flow slicers watch the state cycle and only release
their in-flight-job lock on PREPARE -> ... -> FINISH (or FAILED).
PREPARE -> IDLE looks like "printer abandoned my job" and keeps the
prior job pinned in the slicer's memory.
Fix: transition PREPARE -> FINISH with prepare_percent=100. The 1-Hz
periodic status push broadcasts the new state to every connected
slicer within a second. Send-flow slicers don't watch this state so
the change is a no-op for them; Print-flow slicers see the FINISH
they were waiting for and unwedge.
maziggy
0d6171dc9a