mirror of
https://github.com/maziggy/bambuddy.git
synced 2026-09-30 11:12:35 +02:00
maziggy
a849759469
The sidecar caps model uploads and reports a rejection as a bare HTTP 500 "File too large" -- multer's MulterError is not the sidecar's AppError, so its handler falls through to the default status. A 500 reads as a crash inside the slicer, and the one message Bambuddy had about request size was written for the 413 a reverse proxy sends, so it never appeared. The reporter tried MAX_FILE_SIZE, BODY_PARSER_LIMIT and EXPRESS_PAYLOAD_LIMIT, stopped nginx, and moved from Windows to Docker -- none of which the sidecar reads. Match the rejection by what it says rather than by its status, so an installation still on an older sidecar image gets the same explanation. The 500 match is strict -- the body must be only multer's message -- because a genuine CLI failure is also a 500 and has to keep reaching the embedded-settings fallback. Old images are told to update, since they have no setting to change; current ones are told which one to set. Raising SlicerInputError rather than SlicerApiServerError is also what skips the fallback retry, which had been re-uploading the identical oversized file after a second 25-second 3MF conversion. Log the model size on every slice. Nothing recorded it, so a support package from a slice that died on an upload cap looked exactly like one that died on a bad profile, and this had to be sized by hand. Fall back to the exception class name when a transport error stringifies empty -- three lines of the reporter's log read "Slicer sidecar unreachable: " and stopped there. Needs a sidecar image update to take full effect; MAX_MODEL_UPLOAD_MB is documented in slicer-api/.env.example.