[pppanghu77]

Root Cause Analysis

After network interruption and recovery, re-sending files causes progress to stick at 1%. The root cause is _file_stats not being reset: initOnlineState() (transferhepler.cpp:65-66) only emits interruption() on network change without canceling in-flight jobs or resetting _file_stats. In handleFileTransStatus() (transferworker.cpp:262-327), all_current_size retains stale values from the interrupted transfer, causing progress = stale_value / new_total × 100 ≈ 1%. Neither sendFiles() nor Retransfer() resets _file_stats at entry.

Fix

Two complementary layers: (1) Root cause layer — in initOnlineState(), call cancelTransferJob() and resetFileStats() before Q_EMIT interruption() to cancel in-flight jobs and clear stale stats on network interruption. (2) Symptom layer — call resetFileStats() at sendFiles() entry as a defensive guard covering all call paths including Retransfer().

Change Safety Assessment

Code Safety

• Risk Level: Low
• Target behavior (Q_EMIT interruption() in initOnlineState()) was introduced by PMS 246087 (8ea4fec0); this change does not revert that fix — the interruption signal still fires, and the unfinished-file recording lambda remains connected
• New resetFileStats() is a simple zeroing of three fields; cancelTransferJob() is an existing method reused in a new call site; no function signatures changed, no public members modified

Business Impact Scope

• File Transfer module: progress calculation after network interruption recovery
• User scenario: progress bar no longer sticks at 1% after network recovery; starts from 0% and advances normally
• Retransfer path: retransferring unfinished files also shows correct progress
• Normal network file transfer flow has no behavior change

Verification Suggestion

1. Test file transfer progress advances 0% → 100% under normal network conditions
2. Test re-sending files after network interruption/recovery — progress should start from 0%
3. Test Retransfer of unfinished files — progress should advance correctly

---

根因分析

网络中断恢复后重新投送文件，进度卡在 1%。根因是 _file_stats 未重置：initOnlineState()（transferhepler.cpp:65-66）检测到网络变化时仅发出 interruption() 信号，不取消在途任务也不重置 _file_stats。handleFileTransStatus()（transferworker.cpp:262-327）中 all_current_size 保留中断传输的残留值，导致进度 = 残留值 / 新总量 × 100 ≈ 1%。sendFiles() 和 Retransfer() 入口均不重置 _file_stats。

修复方案

两层互补修复：(1) 根因层 — initOnlineState() 中在 Q_EMIT interruption() 前调用 cancelTransferJob() 取消在途任务并调用 resetFileStats() 重置统计。(2) 症状层 — sendFiles() 入口处防御性调用 resetFileStats()，覆盖含 Retransfer() 在内的所有调用路径。

改动安全评估

代码安全评估

• 风险等级: 低风险
• 目标行为（initOnlineState() 中的 Q_EMIT interruption()）由 PMS 246087（8ea4fec0）引入；本次改动不撤销该修复——中断信号仍正常发出，未完成文件记录 lambda 仍保持连接
• 新增 resetFileStats() 仅置零三个字段；cancelTransferJob() 为已有方法在新调用点复用；未修改函数签名，未修改公开成员变量

业务影响范围

• 文件传输模块：网络中断恢复后重新投送文件的进度计算
• 用户场景：进度条不再卡在 1%，从 0% 正常推进
• Retransfer 路径：重传未完成文件时进度同样正常推进
• 正常网络条件下文件传输流程无行为变化

验证建议

1. 测试正常网络条件下文件传输进度从 0% 推进到 100%
2. 测试网络中断恢复后重新投送文件，进度从 0% 正常推进
3. 测试 Retransfer 路径重传未完成文件，进度正常推进

PMS: BUG-244361

[sourcery-ai]

Sorry, we are unable to review this pull request

The GitHub API does not allow us to fetch diffs exceeding 20000 lines

[deepin-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: pppanghu77

The full list of commands accepted by this bot can be found here.

Details

Needs approval from an approver in each of these files:

• debian/deepin/OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[github-actions]

TAG Bot

TAG: 0.8.9
EXISTED: no
DISTRIBUTION: unstable