[server] Fix file copy for objects larger than 5GB #7992
Conversation
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
ℹ️ About Codex in GitHub
Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
| // Step 2: Upload parts | ||
| fileSize := req.SourceS3Object.FileSize | ||
| numParts := (fileSize + multipartCopyPartSize - 1) / multipartCopyPartSize | ||
| completedParts := make([]*s3.CompletedPart, numParts) |
There was a problem hiding this comment.
The new multipart copy implementation declares numParts := (fileSize + multipartCopyPartSize - 1) / multipartCopyPartSize as an int64, and then uses it both as the length argument to make and as the index variable (completedParts[i]). Go’s make and slice indices require int, so this file no longer compiles (cannot use numParts (type int64) as type int). Until numParts (and the loop index) are converted to int, copyS3ObjectMultipart cannot even build, preventing the server from compiling at all.
Useful? React with 👍 / 👎.
|
@codex review |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
ℹ️ About Codex in GitHub
Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
| fileSize := req.SourceS3Object.FileSize | ||
| numParts := (fileSize + multipartCopyPartSize - 1) / multipartCopyPartSize | ||
| completedParts := make([]*s3.CompletedPart, numParts) | ||
|
|
There was a problem hiding this comment.
The new multipart helper declares numParts := (fileSize + multipartCopyPartSize - 1) / multipartCopyPartSize as an int64 and then passes it directly to make([]*s3.CompletedPart, numParts). In Go the length argument to make must be of type int, so this code does not compile (cannot use numParts (variable of type int64) as type int). As written the server cannot be built, so the copy fix never ships. Cast numParts to int (or derive the slice length from len) before calling make.
Useful? React with 👍 / 👎.
| } | ||
|
|
||
| completedParts[i] = &s3.CompletedPart{ | ||
| ETag: uploadPartOutput.CopyPartResult.ETag, |
There was a problem hiding this comment.
Inside the multipart copy loop i is declared as int64 (for i := int64(0); i < numParts; i++ {) but later used to index completedParts (completedParts[i] = …). Slice indices must be of type int, so this line also fails to compile (invalid operation: cannot use i (variable of type int64) as type int). Until the index is converted to int (or the loop is rewritten to use an int counter), the new multipart copy implementation cannot be built or run.
Useful? React with 👍 / 👎.
Description
Copying large files was resulting in EntityTooLarge error.
Tests