fix: preserve original filename in multipart file upload#1767
Conversation
BuildFormdata read local files into a bytes.Reader before handing them to the SDK, so the SDK's part-filename detection (which only reads *os.File) fell back to "unknown-file" for every local --file upload. Use AddFileWithName with the file's basename instead.
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
🚧 Files skipped from review as they are similar to previous changes (1)
📝 WalkthroughWalkthroughBuildFormdata now uses the local file basename as the multipart filename for non-stdin uploads. The oapi-sdk-go dependency was updated, and multipart-focused tests were added in cmd/api and cmd/service to verify filename handling and form-field contents. ChangesFilename preservation in multipart uploads
Estimated code review effort: 2 (Simple) | ~12 minutes Possibly related PRs
Suggested reviewers: 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #1767 +/- ##
==========================================
+ Coverage 74.39% 74.43% +0.03%
==========================================
Files 860 860
Lines 89481 89754 +273
==========================================
+ Hits 66571 66809 +238
- Misses 17750 17765 +15
- Partials 5160 5180 +20 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
🚀 PR Preview Install Guide🧰 CLI updatenpm i -g https://pkg.pr.new/larksuite/cli/@larksuite/cli@cc9f4983bcf6c4bc032b31ed1882389bd557edcb🧩 Skill updatenpx skills add larksuite/cli#fix/upload-filename-lost -y -g |
Summary
lark-cli api --file <path>built every multipart file part with a hardcodedunknown-filename, because the local-file branch handed the SDK a bare*bytes.Reader(which has noName()). On the approval attachment uploadendpoint, the backend derives the attachment's display name from that part
filename, so approval attachments showed up as "unknown file" instead of e.g.
invoice.pdf. This is a shared-layer defect affecting all generic--fileuploads, not approval alone.
Changes
github.com/larksuite/oapi-sdk-go/v3from v3.5.4 to v3.7.2 to get thefilename-aware
Formdata.AddFileWithNameAPI. This bump spans two minors andalso touches the SDK's token-signing path (tenant-token precedence, a new
client-assertion mode, an added error return). Those are a no-op for this CLI:
it builds its client with token caching disabled, no client-assertion
provider, a single pinned access-token type, and an explicitly supplied token,
so none of the changed branches are reached and the outbound
Authorizationheader is byte-identical across the two SDK versions.
internal/cmdutil/BuildFormdata, the local-file branch now callsAddFileWithName(fieldName, filepath.Base(filePath), reader), so themultipart part carries the real basename. The stdin branch is unchanged
(
--file -keeps theunknown-filefallback — no stable local name).cmd/apiandcmd/servicethat parse thecaptured multipart body and assert the part filename (basename,
field=path,--datacoexistence, stdin fallback).Test Plan
go test ./internal/cmdutil ./cmd/api ./cmd/service— the new tests parsethe captured
multipart/form-databody and assert theContent-Dispositionfilename is the real basename (and
unknown-filefor stdin).go build ./...,go vet ./...,go mod tidy(no residual diff), andgo-licenses check— all clean.pre-fix build and with this fix, then read back the created approval instance's
attachment display name. Pre-fix build showed the attachment as
unknown-file(reproducing the Approval attachment uploads lose filename and show as unknown file #729 symptom); this fix showed the original filename.
Confirmed with a non-ASCII (CJK) filename, which is preserved byte-for-byte end
to end.
Related Issues
Fixes #729
Summary by CodeRabbit
Bug Fixes
Tests