Fix truncated upload of size-changed (SMFix) G-code — Content-Length mismatch

[VGottselig]

Problem

When SMFix post-processing changes a G-code file's size and no fixed file was pre-saved to disk (the default — no -o / OutputDir), HTTPConnector.Upload streams the fixed content but announces the original (pre-fix) size as the multipart FileSize / Content-Length.

req.FileUpload.FileSize is read when the struct is built, but StreamContent only updates payload.Size asynchronously, inside its pipe goroutine (connector.go):

pr, pw := io.Pipe()
go func() {
    cont, err := postProcess(p.File)
    ...
    p.Size = int64(len(cont)) // too late — FileSize was already captured
    pw.Write(cont)
    pw.Close()
}()
return pr, nil

So the request advertises the wrong length. The Snapmaker receives a size-mismatched multipart body, silently discards it (the HTTP call still returns OK to sm2uploader) and keeps the previously loaded job — a following print start then prints the old file. The effect scales with size; large fixed uploads are hit hardest (progress stalls near ~99–100 %, printer keeps the previous file, no error surfaced).

Fix

For the post-processed-without-FixedFile path, materialize the fixed content up front via GetContent and set FileSize to its exact length.

Non-fixed uploads and OutputDir / FixedFile uploads keep streaming unchanged — their payload.Size is already correct before Upload runs, so no behavior change there. The pipe path already buffered the whole fixed file in memory (postProcess returns a full []byte), so there is no added memory cost for the fixed path either.

Testing

• go build ./... clean.
• 65+ MB OrcaSlicer uploads now land on the printer and start the correct file (previously the printer silently kept the prior job).