[liangyuR]

描述

修复 WebDAV 远端文件提交中的错误处理：直接调用 DELETE，完整的 DELETE 404 继续由 webdav_client 当作成功；其他删除错误正常上抛，不再通过额外目录查询将错误吞掉。上传、目标删除或重命名失败后，补充清理临时文件即使再次失败，也只记录清理异常并保留最初的错误。

删除了不再需要的存在性回调和删除辅助方法。目录创建时的存在性查询保持原有行为。本 PR 不修改超时策略、不增加删除前查询，也不改变先上传临时文件再替换目标文件的顺序。

保留 4 项回归测试：真实 loopback HTTP 下 DELETE 404 继续同步且无额外存在性查询、DELETE 403 终止且不上传、正常清理与上传顺序、清理失败不覆盖上传原错。没有新增 widget 测试。

关联的 Issues

Refs #2658

本 PR 改善错误传播与诊断，未验证 issue 作者服务端的实际失败原因，不自动声明该 issue 已解决。

PR 类型

• Bug 修复
• 添加新功能
• 重构实现
• 文档或格式
• 其它

AI 辅助开发

• 没有使用 AI 辅助
• AI 辅助开发了部分功能，但是我已检查并理解 AI 所写的代码
• 基本上都由 AI 实现，但是我非常了解 AI 的代码与写完的产物

AI 辅助模型: OpenAI GPT-6（Codex）。

代码、回归测试和描述由 Codex 按提交者指示编写；涉及提交者本人理解程度的声明留待本人确认。

提交前检查

• 我已经填写了 PR 模板中的所有内容
• 我已经阅读了 贡献指引 ，并遵守指引进行开发
• 这个 PR 的功能已经经过我的测试，并且我完全理解我（或 AI）做出的改动

实际执行的验证（2026-10-18，独立 PR 工作树）：

• flutter test --no-pub：217 项通过，包含保留的 4 项清理回归。
• flutter analyze --no-pub --no-fatal-infos --fatal-warnings：无错误、无警告；17 条既有 info。
• git diff --check 通过。
• 本 PR 仅修改 WebDAV 调用、远端文件提交器及现有服务测试，未混入其他分支的修改。

附注

本机 Flutter 3.47.6 / Dart 3.13.5，使用既有缓存依赖运行上述检查；分支声明 Flutter 3.47.7，尚未在该版本进行干净依赖验证。未修改 SDK 或依赖要求。

未连接 issue 作者的实际服务端。此前本地复现确认完整 DELETE 404 被依赖库接受，因此不将 404 本身描述为失败根因，也不宣称已验证作者服务端截断响应的原因。

已读取贡献指引。描述由 AI 根据提交者指示整理，关于作者本人填写与理解程度的声明未代为确认。请求超时策略留待独立讨论。

[kilo-code-bot]

Code Review Summary

Status: No Issues Found | Recommendation: Merge

Incremental review (2be0e85 → d7d56c9): WebDavRemoteFileCommitter.replaceFile now calls remove directly. The exists callback, _removeIfExists and the WebDavRemoteEntryExists typedef are gone. Errors from DELETE are no longer swallowed after an extra directory lookup, so a 403 on DELETE now stops the sync before anything is uploaded. A full DELETE 404 still counts as success, which the new loopback test covers. _remoteEntryExists (still used by _ensureRemoteDirectory) is back to the same code as main. If cleanup fails after an upload, rename or target-delete failure, the cleanup error is logged and the original error is rethrown.

The updated tests match the new flow: DELETE 404 syncs with no PROPFIND and the order is DELETE/PUT/DELETE/MOVE; DELETE 403 aborts after one DELETE and uploads nothing; cleanup failure keeps the upload error.

Note: servers that answer DELETE on a missing path with something other than 404 (for example 403/409) were tolerated before and will now fail the sync. The PR description says this is intentional.

Files Reviewed (3 files)

• lib/services/sync/webdav.dart
• lib/services/sync/webdav_remote_file_commit.dart
• test/webdav_service_test.dart

Previous Review Summaries (2 snapshots, latest commit 2be0e85)

Current summary above is authoritative. Previous snapshots are kept for context only.

Previous review (commit 2be0e85)

Status: No Issues Found | Recommendation: Merge

Incremental review (a6fa654 → 2be0e85): the new commit takes out the WebDAV connect/send/receive timeout settings that earlier commits in this PR had added. The lookup timeout regression test and its timeout assertions are removed along with them. Neither the timeout settings nor that test exist on the base branch, so init() now matches main. The remaining cleanup tests (missing files and forbidden lookup) still match the current implementation.

Files Reviewed (2 files)

• lib/services/sync/webdav.dart
• test/webdav_service_test.dart

Previous review (commit a6fa654)

Status: No Issues Found | Recommendation: Merge

Files Reviewed (3 files)

• lib/services/sync/webdav.dart
• lib/services/sync/webdav_remote_file_commit.dart
• test/webdav_service_test.dart

---

_{Reviewed by claude-opus-5.5 · Input: 262 · Output: 3.1K · Cached: 266.3K}

[Predidit]

非常抱歉，最近的PR实在太多了，我错过了这个

60秒的超时是否过长，这是很罕见的设置，我们真的要这样设置吗

我们的 webdav 很多情况下不能干净地失败，需要等待硬超时，例如目标服务离线

我们能否先考虑解决修复同步清理问题，这看上去会覆盖大部分失败情况

超时的修改可以另外讨论

[liangyuR]

非常抱歉，最近的PR实在太多了，我错过了这个

60秒的超时是否过长，这是很罕见的设置，我们真的要这样设置吗

我们的 webdav 很多情况下不能干净地失败，需要等待硬超时，例如目标服务离线

我们能否先考虑解决修复同步清理问题，这看上去会覆盖大部分失败情况

超时的修改可以另外讨论

done

[Predidit]

我有一个小问题，webdav_client 收到 DELETE 404 似乎本来就当作成功

如果这样的化，这个PR的修复是否有效

[liangyuR]

你说的有道理，这个东西不必要，“删除之前为什么要先查询，只要服务端不抛异常，直接删就行”

[Predidit]

在两个主要修改都被撤销后，剩下的修改主要在解决什么问题，有复现步骤吗

[liangyuR]

隔得有点久，我原本是为了解决 同步无限等待 这个问题的。 本地复现一下再推

[liangyuR]

这个PR废了，关闭