fix(drivers/guangyapan): report multipart upload progress to copy task - #2989
Conversation
multipartUploadToOSS passed the UpdateProgress callback into stream.NewStreamSectionReader, which ignores the up argument, so the callback was never invoked while uploading parts. As a result, cross-storage copy tasks targeting GuangYaPan stayed at 0% and showed no progress bar or speed in the task list. Fix by tracking the uploaded byte count and invoking up after every part is uploaded, keeping consistent with other drivers' upload flow.
This comment was marked as off-topic.
This comment was marked as off-topic.
Sorry, something went wrong.
Dismissed: superseded by a re-issued review in the standard format. Approval decisions are left to human maintainers.
pikachuren
left a comment
pikachuren
left a comment
There was a problem hiding this comment.
🙏 感谢 @hugcabbage 提交！
🤖 AI 自动审核声明：本评审报告由 AI 自动生成，当前使用 Claude Opus 5 模型进行分析。
🎯 结论
✅ 建议 Approve（由维护者人工确认）— 根因定位准确，改动最小，无阻塞问题
📖 概要
fix(drivers/guangyapan): report multipart upload progress to copy task · 修复跨存储复制到 guangyapan 时进度条长期停在 0%。
核心改动：在分片上传循环中自行累加已上传字节数并回调 up，不再依赖 NewStreamSectionReader 内部上报。
🧭 整体方案
技术路线是「在 driver 侧自行统计进度」而非改动公共库：因为 internal/stream 的 NewStreamSectionReader(file, sectionSize, up *model.UpdateProgress) 根本没有使用传入的 up 参数，driver 交进去的回调永远不会被触发。在 driver 内累加上报属于当前最小、最安全的修法，方案合理。
📊 变更统计
1 个文件（+5 / -0 行） | 功能 ⭐⭐⭐⭐⭐ | 最小改动 ⭐⭐⭐⭐⭐ | 前向兼容 ⭐⭐⭐⭐⭐ | 方案设计 ⭐⭐⭐⭐
🚨 关键问题
P0（阻塞合并）：无
P1（建议修复）：无
P2（可选）：
- 💡 进度仅在每个分片完成后上报，
calcUploadPartSize给出较大分片时进度条会一跳一跳。是否考虑在UploadPart的输入流上包一层计数 reader 让进度更平滑呢？不过要注意retry.Do重试时需要回退计数，否则可能超过 100%——从这个角度看当前写法在重试语义上反而更安全，个人倾向保持现状，仅供参考~ - 💡 循环结束时进度已到 100%，但此时
CompleteMultipartUpload尚未返回，UI 上会先满格再等一会儿。想确认一下这是刻意为之，还是可以把最后一格留给 complete 阶段？
📂 逐文件分析
drivers/guangyapan/util.go
改动意图：让分片上传过程把进度回调给上层复制任务。
代码逻辑：以 file.GetSize() 为分母，循环内累加每个分片的真实字节数 length（末片已截断），换算成 0–100 的百分比调用 up。
问题分析：变量取值与边界都核对过了，末片截断后 length 仍是真实长度，累加结果不会超出 total，百分比口径也与其它 driver 一致，没有发现问题。
详细建议：无需改动。
✅ 待处理清单
- [P2] 确认分片粒度进度跳变是否可接受（如需平滑需处理重试回退）
- [P2] 确认 100% 提前于
CompleteMultipartUpload的展示效果是否符合预期
🔎 顺带一提（不属于本 PR 范围）
internal/stream 的 NewStreamSectionReader 接收了 up *model.UpdateProgress 却完全没有使用，这是个比较容易踩的陷阱——本 PR 踩到了，其它 driver 可能也存在同样问题。是否考虑单开一个 issue，把这个死参数删掉或者真正接上呢？这样能从源头避免同类问题复现~
🎯 结论：✅ 建议 Approve — 根因准确、改动最小、无阻塞问题，仅剩两条可选的体验优化。
3 participants
Summary / 摘要
修复 GuangYaPan 驱动 OSS 分片上传不更新任务进度的问题。
背景：从其他存储（跨存储复制）复制到光鸭云盘时，OpenList 会创建
FileTransferTask并通过GuangYaPan.Put->multipartUploadToOSS上传，但该函数把进度回调
up传入stream.NewStreamSectionReader后从未再调用，而
NewStreamSectionReader的实现会忽略up参数，导致任务进度始终为 0，任务列表不显示进度条和速度。
修复：在
multipartUploadToOSS的分片循环中累计已上传字节数，并在每个分片上传完成后调用
up(100 * uploaded / total)上报进度，与其他驱动保持一致的实现方式。
Behavior changes / 用户可感知的行为变化
进度条与速度（此前停留在 0%）。
copy_file异步任务，不经任务系统）。Implementation changes / 重要实现变化
drivers/guangyapan/util.go：multipartUploadToOSS新增uploaded累计计数，每分片上传成功后调用
up上报百分比进度。/ 此 PR 包含破坏性变更。
/ 此 PR 修改了公开 API、配置、存储格式或迁移行为。
/ 此 PR 需要关联仓库同步修改。
Related repository PRs / 关联仓库 PR:
Related Issues / 关联 Issue
Relates to #2970
Testing / 测试
go build ./drivers/guangyapan/go test ./...Checklist / 检查清单
/ 我已阅读 CONTRIBUTING。
/ 我确认此贡献符合仓库许可证、贡献规范和行为准则。
gofmt,go fmt, orprettierwhere applicable./ 我已按适用情况使用
gofmt、go fmt或prettier格式化变更代码。/ 我已在适用情况下请求相关维护者或代码所有者审查。
AI Disclosure / AI 使用声明
/ 此 PR 包含 AI 辅助内容。
Tools used / 使用工具:
Usage scope / 使用范围:
/ 我已审核并验证此 PR 中的所有 AI 辅助内容。
Co-Authored-Byattribution./ 我已确保所有 AI 辅助提交都包含
Co-Authored-By归属信息。/ 我可以在没有任何 AI 工具的情况下重现此 PR 中包含的所有 AI 辅助内容。