[GH-ISSUE #1042] [Bug]: Unable to despatch print jobs due to task_id bounding

BreizhHardware commented

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

Owner

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

Originally assigned to: @maziggy on GitHub.

Component

Bambuddy

Bug Description

Background dispatch could report success even when the printer did not actually start. The MQTT project_file response returned result: success, but on my P1S the printer stayed IDLE, later reported FAILED, and never moved into PREPARE or RUNNING.

Root causes found:

project_file result=success only confirms command acceptance, not print start.
P1S firmware appears to clamp oversized task identity fields to signed 32-bit max. Logs showed the app sending 13-digit timestamp IDs, then the printer reporting task_id: 2147483647. After bounding IDs below 2147483647, the P1S started the job correctly.
P1S does not support automatic bed detection, so sending "bed_type": "auto" is risky. Sliced 3MF already contains the correct plate type in Metadata/plate_N.json, e.g. "textured_plate", so the command should use that.

Required fix:

Generate non-zero, per-submission project_id, subtask_id, and task_id, but keep them below signed 32-bit max.
Resolve bed_type from the sliced 3MF metadata and pass it into project_file.
Do not treat project_file result=success as dispatch success. Confirm a real state transition to PREPARE, RUNNING, or PAUSE; otherwise fail/retry instead of reporting success.
Apply the bed-type handling to both background dispatch and queue dispatch so behaviour is consistent.
Evidence:

Failing P1S command used 13-digit IDs like 1776636009678.
Printer then reported task_id: 2147483647, gcode_state: FAILED, empty gcode_file, and did not move.
After changing IDs to signed-31-bit range and using the concrete 3MF bed type, the P1S dispatch started correctly.

Expected Behavior

Print despatches and print starts.

Steps to Reproduce

Click print,
upload file,
despatch "successful"
not print begins

Printer Model

P1S

Bambuddy Version

v0.2.4b1[dev branch]

SpoolBuddy Version

No response

Printer Firmware Version

01.10.00.00

Installation Method

Manual (git clone)

Operating System

macOS

Relevant Logs / Support Package

bambuddy-support-20260419-231950.zip

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 @EdwardChamberlain on GitHub (Apr 19, 2026). Original GitHub issue: https://github.com/maziggy/bambuddy/issues/1042 Originally assigned to: @maziggy on GitHub. ### Component Bambuddy ### Bug Description Background dispatch could report success even when the printer did not actually start. The MQTT project_file response returned result: success, but on my P1S the printer stayed IDLE, later reported FAILED, and never moved into PREPARE or RUNNING. Root causes found: - project_file result=success only confirms command acceptance, not print start. - P1S firmware appears to clamp oversized task identity fields to signed 32-bit max. Logs showed the app sending 13-digit timestamp IDs, then the printer reporting task_id: 2147483647. After bounding IDs below 2147483647, the P1S started the job correctly. - P1S does not support automatic bed detection, so sending "bed_type": "auto" is risky. Sliced 3MF already contains the correct plate type in Metadata/plate_N.json, e.g. "textured_plate", so the command should use that. Required fix: - Generate non-zero, per-submission project_id, subtask_id, and task_id, but keep them below signed 32-bit max. - Resolve bed_type from the sliced 3MF metadata and pass it into project_file. - Do not treat project_file result=success as dispatch success. Confirm a real state transition to PREPARE, RUNNING, or PAUSE; otherwise fail/retry instead of reporting success. - Apply the bed-type handling to both background dispatch and queue dispatch so behaviour is consistent. Evidence: Failing P1S command used 13-digit IDs like 1776636009678. Printer then reported task_id: 2147483647, gcode_state: FAILED, empty gcode_file, and did not move. After changing IDs to signed-31-bit range and using the concrete 3MF bed type, the P1S dispatch started correctly. ### Expected Behavior Print despatches and print starts. ### Steps to Reproduce Click print, upload file, despatch "successful" not print begins ### Printer Model P1S ### Bambuddy Version v0.2.4b1[dev branch] ### SpoolBuddy Version _No response_ ### Printer Firmware Version 01.10.00.00 ### Installation Method Manual (git clone) ### Operating System macOS ### Relevant Logs / Support Package [bambuddy-support-20260419-231950.zip](https://github.com/user-attachments/files/26877500/bambuddy-support-20260419-231950.zip) ### 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:13:17 +02:00

closed this issue
added the
bug
label

BreizhHardware commented

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

Author

Owner

@EdwardChamberlain commented on GitHub (Apr 19, 2026):

github.com/maziggy/bambuddy@5303673582/backend/app/services/bambu_mqtt.py (L3023-L3024)

Should probably be:

submission_id_int = int(time.time() * 1000) % 2_147_483_647
submission_id = str(submission_id_int or 1)

@EdwardChamberlain commented on GitHub (Apr 19, 2026): https://github.com/maziggy/bambuddy/blob/5303673582bebfb74ab7ad49765712db0cd3241b/backend/app/services/bambu_mqtt.py#L3023-L3024 Should probably be: ```py submission_id_int = int(time.time() * 1000) % 2_147_483_647 submission_id = str(submission_id_int or 1) ```

BreizhHardware commented

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

Author

Owner

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

Good catch — your analysis is exactly right, and the mod-by-INT32_MAX fix is landing on dev as-is (with or 1 guarding the zero edge case, as you wrote). Regression test asserts all three IDs < 2**31 so this can't regress silently.

On your other three points:

3MF bed_type from Metadata/plate_N.json — agreed, "bed_type": "auto" is wrong for P1S. Tracking this separately because it also needs to be consistent between background dispatch and queue dispatch (you called this out), and I want to share the resolver logic with the existing plate-metadata parser instead of duplicating it.
Don't treat project_file result=success as dispatch success — also agreed, this is a structural fix. The right place to wait for the real state transition is the same status-watcher that already gates queued-print completion, but it needs a new "awaiting first transition" state with a sensible timeout. Will track in its own issue.
Apply bed-type handling to background + queue dispatch — will roll into the first item.

For now the int32 fix alone should get your P1S dispatching reliably on the next daily build — please confirm when you've tested it. Thanks again for the detailed repro with the exact IDs.

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 20, 2026): Good catch — your analysis is exactly right, and the mod-by-INT32_MAX fix is landing on dev as-is (with or 1 guarding the zero edge case, as you wrote). Regression test asserts all three IDs < 2**31 so this can't regress silently. On your other three points: - 3MF bed_type from Metadata/plate_N.json — agreed, "bed_type": "auto" is wrong for P1S. Tracking this separately because it also needs to be consistent between background dispatch and queue dispatch (you called this out), and I want to share the resolver logic with the existing plate-metadata parser instead of duplicating it. - Don't treat project_file result=success as dispatch success — also agreed, this is a structural fix. The right place to wait for the real state transition is the same status-watcher that already gates queued-print completion, but it needs a new "awaiting first transition" state with a sensible timeout. Will track in its own issue. - Apply bed-type handling to background + queue dispatch — will roll into the first item. For now the int32 fix alone should get your P1S dispatching reliably on the next daily build — please confirm when you've tested it. Thanks again for the detailed repro with the exact IDs. 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 commented

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

Author

Owner

@EdwardChamberlain commented on GitHub (Apr 25, 2026):

Confirm working.

There are still cases that the P1S fails to begin such as when the printer is in a serious error state (SD card failed seems to do it). This is fine, but the UI reports despatch success which is slightly misleading as it is still using the transmission as success criteria. As mentioned here:

Don't treat project_file result=success as dispatch success — also agreed, this is a structural fix. The right place to wait for the real state transition is the same status-watcher that already gates queued-print completion, but it needs a new "awaiting first transition" state with a sensible timeout. Will track in its own issue.

This seems to differ from the queue behaviour which looks to have a watchdog style check to confirm despatch.

Do you want me to raise a separate issue for this as it looks like there isnt one for this.

@EdwardChamberlain commented on GitHub (Apr 25, 2026): Confirm working. There are still cases that the P1S fails to begin such as when the printer is in a serious error state (SD card failed seems to do it). This is fine, but the UI reports despatch success which is slightly misleading as it is still using the transmission as success criteria. As mentioned here: > Don't treat project_file result=success as dispatch success — also agreed, this is a structural fix. The right place to wait for the real state transition is the same status-watcher that already gates queued-print completion, but it needs a new "awaiting first transition" state with a sensible timeout. Will track in its own issue. This seems to differ from the queue behaviour which looks to have a watchdog style check to confirm despatch. Do you want me to raise a separate issue for this as it looks like there isnt one for this.

BreizhHardware commented

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

Author

Owner

@EdwardChamberlain commented on GitHub (Apr 25, 2026):

Actually looks like this is not fixed. Still seeing issues with background despatch and queues. Not sure if this is the timestamping or something else but same symptoms - no job starts. This is present in both latest release and dev branch.

bambuddy-support-20260425-180219.zip

@EdwardChamberlain commented on GitHub (Apr 25, 2026): Actually looks like this is not fixed. Still seeing issues with background despatch and queues. Not sure if this is the timestamping or something else but same symptoms - no job starts. This is present in both latest release and dev branch. [bambuddy-support-20260425-180219.zip](https://github.com/user-attachments/files/27087144/bambuddy-support-20260425-180219.zip)

BreizhHardware commented

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

Author

Owner

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

Thanks for the new support pack. I want to split this into the two things that have been getting tangled together, because the new logs actually confirm one of them:

1. The int32 fix is working — verified by your own logs.

The two project_file dispatches in the new pack are:

18:00:15.351 (queue path) → task_id: 1167439282
18:02:03.592 (background path) → task_id: 1167547522

Both well below 2^31-1 (2147483647), and both match 'int(time.time() * 1000) % 2_147_483_647` exactly for the timestamps
shown. The original 13-digit / clamped-to-INT32-max symptom does not appear anywhere in this log. So the root cause #1042 was opened for is demonstrably gone.

2. What's still failing is the second item from your original list,
not the int32 piece.

Printer 3 (P1S) is sitting in gcode_state: FAILED from the very first MQTT message in the log, with HMS 0300_400C ("The task was canceled"). Both dispatches succeed at the MQTT level — the printer accepts them — but it never leaves the prior FAILED/cancelled state. The watchdog you asked about does fire on the background-dispatch attempt:

18:02:18 WARNING [background_dispatch] Printer (3) did not respond to
print command within 15s (state still FINISH) — printer may
need restart
18:02:18 WARNING [bambu_mqtt] Forcing MQTT reconnect: print command
unacknowledged after 15s (state still FINISH)

So _verify_print_response is detecting the non-transition correctly (this is the work from #887 / #936 / #967 / #1078). What it doesn't do yet is propagate that signal back to the queue item / archive / WebSocket — it's fire-and-forget, only warns and reconnects MQTT. The UI therefore keeps the optimistic "Print started successfully" message that print_scheduler logs immediately after the publish. That's exactly the residual you flagged in your follow-up comment last week:

"the UI reports despatch success which is slightly misleading"

I'll track this remaining piece (wire the watchdog's "did not respond" outcome back to the queue/archive/UI as a real failure, not just a log warning) as its own issue — the same one I owed you. The bed_type: "auto" cleanup is still also outstanding and gets its own issue.

Leaving #1042 closed since the int32 root cause is fixed; the residual is genuinely a different bug class (success-reporting vs. ID generation), so having it tracked separately keeps the history readable. Will link both follow-ups back here once filed.

@maziggy commented on GitHub (Apr 26, 2026): Thanks for the new support pack. I want to split this into the two things that have been getting tangled together, because the new logs actually confirm one of them: **1. The int32 fix is working — verified by your own logs.** The two `project_file` dispatches in the new pack are: - `18:00:15.351` (queue path) → `task_id: 1167439282` - `18:02:03.592` (background path) → `task_id: 1167547522` Both well below 2^31-1 (2147483647), and both match 'int(time.time() * 1000) % 2_147_483_647` exactly for the timestamps shown. The original 13-digit / clamped-to-INT32-max symptom does not appear anywhere in this log. So the root cause #1042 was opened for is demonstrably gone. **2. What's still failing is the second item from your original list, not the int32 piece.** Printer 3 (P1S) is sitting in `gcode_state: FAILED` from the very first MQTT message in the log, with HMS `0300_400C` ("The task was canceled"). Both dispatches succeed at the MQTT level — the printer accepts them — but it never leaves the prior FAILED/cancelled state. The watchdog you asked about *does* fire on the background-dispatch attempt: > 18:02:18 WARNING [background_dispatch] Printer (3) did not respond to > print command within 15s (state still FINISH) — printer may > need restart > 18:02:18 WARNING [bambu_mqtt] Forcing MQTT reconnect: print command > unacknowledged after 15s (state still FINISH) So `_verify_print_response` is detecting the non-transition correctly (this is the work from #887 / #936 / #967 / #1078). What it doesn't do yet is propagate that signal back to the queue item / archive / WebSocket — it's fire-and-forget, only warns and reconnects MQTT. The UI therefore keeps the optimistic "Print started successfully" message that `print_scheduler` logs immediately after the publish. That's exactly the residual you flagged in your follow-up comment last week: > "the UI reports despatch success which is slightly misleading" I'll track this remaining piece (wire the watchdog's "did not respond" outcome back to the queue/archive/UI as a real failure, not just a log warning) as its own issue — the same one I owed you. The `bed_type: "auto"` cleanup is still also outstanding and gets its own issue. Leaving #1042 closed since the int32 root cause is fixed; the residual is genuinely a different bug class (success-reporting vs. ID generation), so having it tracked separately keeps the history readable. Will link both follow-ups back here once filed.

BreizhHardware commented

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

Author

Owner

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

https://github.com/maziggy/bambuddy/issues/1042
https://github.com/maziggy/bambuddy/issues/1135

@maziggy commented on GitHub (Apr 26, 2026): https://github.com/maziggy/bambuddy/issues/1042 https://github.com/maziggy/bambuddy/issues/1135

BreizhHardware referenced this issue

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

[PR #785] [MERGED] v0.2.2.1 #1116

BreizhHardware referenced this issue

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

[PR #783] [CLOSED] v0.2.2.1 #1120