fix: 30MB 超限防护 — 文档去重 + resume 自动重试

[lishuceo]

Summary

• 话题内多条消息引用同一 PDF 时，文档重复累积超过 API 30MB 限制
• deduplicateDocuments() 按 fileName 去重 + 20MB 总量上限，应用于两个历史合并点
• downloadHistoryFiles 按 fileKey 去重，避免重复下载
• 新增：executor 检测到 "message size exceeds limit" + resume 模式时，自动丢弃旧 session 开新会话重试

Test plan

• 6 个 deduplicateDocuments 单元测试通过
• 全量测试 71/72 files (1 pre-existing flaky)
• 生产验证：session 清除后话题恢复正常

🤖 Generated with Claude Code

[claude]

Claude finished @lishuceo's task in 1m 28s —— View job

---

PR Review: fix: 30MB 超限防护 — 文档去重 + resume 自动重试

• Check for previous review comments
• Read changed files and understand context
• Review code for bugs, security, and architecture issues
• Post review summary

⚠️ Issues Found

Overall this is a well-structured fix for a real production issue. The dedup logic is clean, tests are solid, and the approach is sound. Two items worth discussing:

• 🟡 base64 size accounting (confidence: 80) — doc.data.length measures base64 string length, not decoded bytes. The 20MB cap is actually ~15MB of raw data. This is conservative (safe), but the constant name/comment says "base64 字节数" which is slightly misleading. See inline comment.

• 🟡 Recursive retry side effects (confidence: 85) — The execute() retry without resume is safe against infinite loops (good!), but the recursive call re-runs the full method including onProgress callbacks, which may send duplicate progress cards to the user. See inline comment.

What looks good

• deduplicateDocuments() is clean, well-tested (6 cases), and correctly exported for testing
• Dedup applied consistently in both executeClaudeTask and executeDirectTask
• downloadHistoryFiles fileKey dedup prevents redundant downloads upstream
• Current-message docs prioritized over history docs (correct merge order)
• The recursive retry guard (effectiveResumeId check) naturally prevents infinite loops
• Images are not deduplicated, but they're typically smaller — acceptable for now

---

[claude]

Claude finished @lishuceo's task in 1m 44s —— View job

---

PR Review: fix: 30MB 超限防护 — 文档去重 + resume 自动重试 (re-review after 88c8b08)

• Check previous review comments against new commits
• Read changed files and review new changes
• Post review summary

✅ Approved

2 previous issues resolved — both inline comment threads have been addressed and resolved.

The new commit (88c8b08) takes the right approach by fixing the root cause: on resume, history file attachments are now skipped entirely since the SDK replays all prior turns (files are already in the conversation). This makes the deduplicateDocuments size cap and the executor retry (from 1d84184) defense-in-depth fallbacks rather than primary mitigations.

What's new in 88c8b08

• Resume skip logic in both executeClaudeTask and executeDirectTask: when resuming (activeConversationId / canResume), history images and documents are not merged into the current request
• messageType discrimination: current-message documents are cleared on resume only when messageType !== 'file', correctly distinguishing "user uploaded a new file" from "message quotes a parent that had a file"
• Consistent implementation: the same logic is applied identically in both code paths, with clear comments explaining the rationale

Assessment

The three-layer defense is sound:

1. Root cause fix (88c8b08): skip duplicate file attachments on resume
2. Dedup fallback: deduplicateDocuments() caps non-resume merges at 20MB
3. Last-resort retry (1d84184): executor detects 30MB error + resume → retries without resume

No new issues found with confidence ≥ 75.