starred/bambuddy

Fork 0

mirror of https://github.com/maziggy/bambuddy.git synced 2026-05-09 05:35:30 +02:00

[GH-ISSUE #1212] [Bug]: Archive created successfully but fails to load on reprint/view #878

New issue

Closed

opened 2026-05-06 12:33:37 +02:00 by BreizhHardware · 1 comment

BreizhHardware commented

2026-05-06 12:33:37 +02:00

Owner

Originally created by @abbasegbeyemi on GitHub (May 5, 2026).
Original GitHub issue: https://github.com/maziggy/bambuddy/issues/1212

Originally assigned to: @maziggy on GitHub.

Component

Bambuddy

Bug Description

When triggering a reprint or attempting to view the G-code of a completed print, Bambuddy reports that the archive cannot be found or may have been deleted — despite the archive appearing to have been created successfully at print completion.

Expected Behavior

The archive should be viewable/reprintable

Steps to Reproduce

Complete a print job
Navigate to the print history / archive
Select a completed print and choose "Reprint" or "View G-code"
Reprint says: "Archive can't be found, it may have been deleted"
View G-code just returns {"detail": "not found"}

Printer Model

H2C

Bambuddy Version

v0.2.4b2 (Daily)

SpoolBuddy Version

No response

Printer Firmware Version

No response

Installation Method

Docker

Operating System

Linux (Ubuntu/Debian)

Relevant Logs / Support Package

bambuddy-support-20260505-075651.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 @abbasegbeyemi on GitHub (May 5, 2026). Original GitHub issue: https://github.com/maziggy/bambuddy/issues/1212 Originally assigned to: @maziggy on GitHub. ### Component Bambuddy ### Bug Description When triggering a reprint or attempting to view the G-code of a completed print, Bambuddy reports that the archive cannot be found or may have been deleted — despite the archive appearing to have been created successfully at print completion. ### Expected Behavior The archive should be viewable/reprintable ### Steps to Reproduce 1. Complete a print job 2. Navigate to the print history / archive 3. Select a completed print and choose "Reprint" or "View G-code" 4. Reprint says: "Archive can't be found, it may have been deleted" 5. View G-code just returns `{"detail": "not found"}` ### Printer Model H2C ### Bambuddy Version v0.2.4b2 (Daily) ### SpoolBuddy Version _No response_ ### Printer Firmware Version _No response_ ### Installation Method Docker ### Operating System Linux (Ubuntu/Debian) ### Relevant Logs / Support Package [bambuddy-support-20260505-075651.zip](https://github.com/user-attachments/files/27389377/bambuddy-support-20260505-075651.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-06 12:33:37 +02:00

closed this issue
added the
bug
label

BreizhHardware commented

2026-05-06 12:33:37 +02:00

Author

Owner

@maziggy commented on GitHub (May 5, 2026):

Confirmed and fixed. This is a regression that's been silently destroying archive copies on every print completion since the daily build on Apr 29.

Root cause: a cover-thumbnail optimisation registered the live archive 3mf in a shared download cache so /cover could skip a
redundant FTP fetch mid-print. The cache cleanup that runs on on_print_complete then walked the cache and unlinked every path it knew about — which, post-optimisation, included your actual archive copy. The DB row was untouched, so the archive kept showing up in the list; only when you tried to act on it (Reprint / View G-code) did the missing file surface as a 404.

Your support log was the smoking gun: the print finished at 07:10:48, the cleanup ran, and at 07:15:13 your reprint returned 404 — exactly the window the bug fires in.

The fix lands in the next daily build (today). It gates the cleanup so it only touches files inside archive_dir/temp/ — archive copies under archive/<printer_id>/... and archive/unassigned/... are now left alone, as are library file bytes. A regression test pins the contract so this can't drift.

Bad news: the bytes that were already deleted on your install can't be recovered by this fix — they're gone from disk. Recovery options if you still want those specific archives:

Re-export from your slicer if you still have the source project
If the printer hasn't cleared its FTP root yet, the file may still be resident there — pull it back via FTP and re-import

Going forward, archives created on builds with this fix are safe. Apologies for the silent data loss — this one is on us.

Available/Fixed in branch dev and available with the next release or daily build. Please let me know if it works for you.

If you find Bambuddy useful, please consider giving it a ⭐ on GitHub — it helps others discover the project!

@maziggy commented on GitHub (May 5, 2026): Confirmed and fixed. This is a regression that's been silently destroying archive copies on every print completion since the daily build on Apr 29. Root cause: a cover-thumbnail optimisation registered the live archive 3mf in a shared download cache so /cover could skip a redundant FTP fetch mid-print. The cache cleanup that runs on on_print_complete then walked the cache and unlinked every path it knew about — which, post-optimisation, included your actual archive copy. The DB row was untouched, so the archive kept showing up in the list; only when you tried to act on it (Reprint / View G-code) did the missing file surface as a 404. Your support log was the smoking gun: the print finished at 07:10:48, the cleanup ran, and at 07:15:13 your reprint returned 404 — exactly the window the bug fires in. The fix lands in the next daily build (today). It gates the cleanup so it only touches files inside archive_dir/temp/ — archive copies under archive/<printer_id>/... and archive/unassigned/... are now left alone, as are library file bytes. A regression test pins the contract so this can't drift. Bad news: the bytes that were already deleted on your install can't be recovered by this fix — they're gone from disk. Recovery options if you still want those specific archives: - Re-export from your slicer if you still have the source project - If the printer hasn't cleared its FTP root yet, the file may still be resident there — pull it back via FTP and re-import Going forward, archives created on builds with this fix are safe. Apologies for the silent data loss — this one is on us. Available/Fixed in branch dev and available with the next release or daily build. Please let me know if it works for you. ----- 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-06 12:35:21 +02:00

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