[RAPTOR-20129] fix(filesapi): send zip-path overwrite in the multipart form

[wojtekwdr]

RATIONALE

dr artifact code sync and dr workload up upload through POST /files/{id}/fromFile/ whenever a change set exceeds 20 files or 50 MB. The overwrite mode went only in the query string, which the Files API accepts and ignores, so the server's rename default applied: every existing path came back as name (2).ext holding the new bytes while the original kept the old ones, and an image built from that version ran stale code. Reproduced on staging: a 25-file re-sync produced a 53-file version with 25 duplicates. The Terraform provider carried the same code and fixed it the same way.

CHANGES

• Multipart uploads can carry form fields, framed before the file part so a streaming parser has them before the file.
• UploadFromZipExisting sends overwrite in the form and keeps the query copy until the API documents which location is authoritative.
• Tests pin the field order, the query copy, and an exact Content-Length with fields present.
• Changelog entry under Unreleased / Fixed.

TESTING

Staging, fixed binary, 25 modified files: dr artifact code sync re-sync gives 28 files and no duplicates (53 with 25 duplicates before), and a dr workload up re-deploy gives 27 files and no duplicates, with the server checksum of the edited file matching the local one. task lint on all three GOOS legs and task test are green.

RELATED

PR #867 bundles the same fix with unrelated integrity work and is currently red; this is the standalone extract so it can ship on its own, and #867 can rebase onto it. useArchiveContents staying in the query is RAPTOR-19915.

---

Note

Medium Risk
Changes deploy/sync upload behavior for large change sets; incorrect framing could break uploads, but scope is limited to the zip fromFile path and is covered by new tests.

Overview
Fixes catalog zip uploads (dr artifact code sync and large-change dr workload up paths) so existing files are replaced instead of duplicated. The Files API was ignoring overwrite when it was only on the query string; the server’s rename default produced name (2).ext copies and left old bytes in place, so built images could run stale code.

UploadFromZipExisting now sends overwrite as a multipart form field before the zip part (query param kept for compatibility). Streaming multipart framing was extended to emit optional form fields with correct Content-Length; stage uploads pass no extra fields.

Tests assert form field order, query copy, payload integrity on large bodies, and that new-catalog zip uploads still send only the file part.

^{Reviewed by Cursor Bugbot for commit 8787c8e. Configure here.}

[datarobot-pr-review-router]

🎫 Jira: RAPTOR-20129 — CLI code sync: zip upload sends overwrite mode in the query string, server ignores it and renames every colliding file

[datarobot-pr-review-router]

Code Ownership

Cli Maintainers

• CHANGELOG.md
• internal/drapi/filesapi/client_test.go
• internal/drapi/filesapi/fromfile.go
• internal/drapi/filesapi/multipart.go
• internal/drapi/filesapi/stage.go

Review requested from the teams above. Labels will be removed automatically upon approval.

[wojtekwdr]

/approve-smoke-tests

[github-actions]

🔐 Fork PR smoke tests triggered by @wojtekwdr

⚠️ Security Notice: This will run tests with access to repository secrets.

What happens next:

1. Security scans will run automatically (Trivy, gosec)
2. If security scans pass, smoke tests will run
3. Results will be posted as PR comments

⚠️ Important: Review the PR code carefully before approving!

[github-actions]

🔐 Fork smoke tests started by maintainer

⏳ Security scans passed. Running smoke tests...

Commit: 8787c8e705459c53d21ee902700371e055a6086c
View run

[github-actions]

✅ All smoke tests passed! (Fork PR)

✅ Security Scan: success
✅ Linux: success
✅ Windows: success

View run details