mirror of
https://github.com/maziggy/bambuddy.git
synced 2026-10-01 11:47:46 +02:00
maziggy
8646c40957
The slice client only checked the sidecar's HTTP status, not its body. When the sidecar -- or a reverse proxy in front of it -- returned 200 OK with a body that wasn't a real 3MF (a stock/misconfigured sidecar, a proxy error page, a truncated response, or an OrcaSlicer/Bambu Studio CLI crash emitting no output), Bambuddy wrote that tiny blob to a .gcode.3mf, stored it as a valid sliced file (the 3MF-parse failure was swallowed as "no thumbnail"), and let it be queued and FTP'd to the printer -- producing the ~28-byte files that "did nothing" and then failed at print time. Separately, a genuine 413 comes from the proxy in front of the sidecar rejecting the multi-MB upload (model + profiles), so raising the body limit on the wrong proxy layer had no effect. - Factor the duplicated status handling in slice_with_profiles / slice_without_profiles into one _handle_slice_response. - When a 3MF export was requested, validate the body is a real ZIP; otherwise raise SlicerApiServerError with an actionable message instead of persisting a corrupt file. - Special-case 413 with a message naming client_max_body_size on the proxy directly in front of the sidecar (Cloudflare cap noted).