perf(session): 去重 Redis 中重复存储的 response body

[AptS-1547]

背景

#1414 为 #1408 增加了 SESSION_RESPONSE_BODY_MAX_BYTES，限制单份 session response body
写入 Redis 的大小。当前响应正文仍可能同时写入三类 key：

• legacy/request response：session:{sessionId}:req:{sequence}:response
• response before snapshot body
• response after snapshot body

当 before、after 与最终 response 内容相同或高度重合时，Redis 会保存最多三份完整正文。#1408
的隔离复现中，64 个约 7.5 MiB SSE 响应因此形成约 1.4 GiB 原始正文值，并在 RDB 保存窗口把
Redis 峰值推到约 1.5 GiB。

#1414 先通过单份大小上限控制风险，默认值按当前运维取舍设为 5 MiB；三份复制需要独立设计和
负载验证，避免在 OOM 修复中混入未经验证的数据布局迁移。

目标

• 同一 request sequence 的 response 正文只保留一份物理 Redis value，或使用具有相同内存上界的
  内容寻址/引用机制。
• before、after 和 legacy/request response 继续保持现有读取语义；内容确实不同时仍能分别查看。
• STORE_SESSION_MESSAGES=false 的脱敏结果必须在去重/哈希前生效，原始敏感正文不得通过共享值泄漏。
• 单请求正文总 Redis 预算由一个明确上限控制，不再随视图数量线性放大。

兼容边界

• 兼容 TTL 窗口内由旧版本写入的现有 key；滚动部署期间新旧读取路径可互操作。
• headers/meta 继续独立保存，正文超限或缺失时仍可查看请求阶段、状态码和 URL 等诊断信息。
• STORE_SESSION_RESPONSE_BODY=false 继续完全跳过正文写入。
• 不改变代理响应、token/费用统计、SSE 协议检测或 Replay durable payload 语义。

验收标准

• 为 legacy response、before、after 三者完全相同、两者相同、三者不同分别增加单元测试。
• 增加覆盖脱敏后相同、脱敏后不同、UTF-8 字节上限和旧 key 读取兼容的边界测试。
• 对更新/重试覆盖旧正文的路径验证无悬空引用、无错误复用和 TTL 一致性。
• 使用 物理真机卡死过2次 gpt5.6分析的结果 #1408 仓库负载夹具运行 64 个 5 MiB session response，请求完成后 Redis 正文原始值预算不超过单份上限乘请求数。
• 覆盖 Redis RDB 保存窗口，记录 used_memory_peak、容器峰值、OOM/退出状态和清理后的 key 数量。
• 更新 session response body 配置说明和 物理真机卡死过2次 gpt5.6分析的结果 #1408 调查文档。

关联

• 物理真机卡死过2次 gpt5.6分析的结果 #1408
• fix(proxy): bound Replay disconnect memory retention (#1408) #1414

[coderabbitai]

🔗 Related PRs

#1348 - feat(proxy): add bounded streaming discovery [merged]
#1382 - fix: support canonical and client session detail identities [merged]
#1404 - fix(proxy): support remote compaction v2 passthrough [merged]
#1413 - fix(replay): bound detached stream memory (#1408) [open]
#1414 - fix(proxy): bound Replay disconnect memory retention (#1408) [open]

---

📝 Issue Planner

_{Check the box below or use the @coderabbitai plan command to generate an implementation plan and prompts that you can use with your favorite coding assistant.}

• Create Plan

---

🧪 Issue enrichment is currently in open beta.

You can configure auto-planning by selecting labels in the issue_enrichment configuration.

To disable automatic issue enrichment, add the following to your .coderabbit.yaml:

issue_enrichment:
  auto_enrich:
    enabled: false

💬 Have feedback or questions? Drop into our discord!

[github-actions]

Thank you for this well-scoped enhancement and the detailed acceptance criteria.

Confirmation of the three-way amplification

My reading of the code confirms the diagnosis. Within a single non-streaming request, response-handler.ts writes the response body to three independent Redis keys:

• session:{sessionId}:req:{sequence}:response via SessionManager.storeSessionResponse(...) — src/app/v1/_lib/proxy/response-handler.ts:2563
• session:{sessionId}:req:{sequence}:snapshot:response:before:body via storeSessionResponsePhaseSnapshot(..., "before", { body: beforeBody }) — response-handler.ts:2572, where beforeBody = (await consumeBeforeResponseBodySnapshot(session)) ?? responseText (response-handler.ts:2562)
• session:{sessionId}:req:{sequence}:snapshot:response:after:body via storeSessionResponsePhaseSnapshot(..., "after", { body: responseText }) — response-handler.ts:2583

The snapshot keys are constructed by buildSessionDetailSnapshotKey() (src/lib/session-manager.ts:151-159). When no distinct before-snapshot was captured, beforeBody falls back to responseText, so all three keys hold byte-identical content — the 3x amplification described. The same three-write pattern repeats at response-handler.ts:3140, 3850, and 4409.

Prerequisite status (#1414)

For tracking: #1414 (the SESSION_RESPONSE_BODY_MAX_BYTES per-copy cap) is currently OPEN / not merged, and SESSION_RESPONSE_BODY_MAX_BYTES is not yet present in src/lib/config/env.schema.ts:148-159. So this dedup work correctly sits behind it.

Implementation considerations grounded in the current code

1. Redaction must precede any hash/dedup-key derivation. Today, redaction runs at write time on the value before setex: legacy path at session-manager.ts:2066-2083, snapshot path at session-manager.ts:2674-2688. A content-addressable scheme must hash the post-redaction bytes; hashing pre-redaction raw bodies would leak sensitive content through a shared value (the compatibility boundary the issue calls out), and hashing neither would let two requests that redact to the same [REDACTED] body incorrectly share a value while their raw bodies differ. Hashing post-redaction preserves the existing STORE_SESSION_MESSAGES=false contract.

2. Read paths are independent and must stay so. src/actions/active-sessions.ts:1048-1100 reads all three via separate calls — getSessionResponse (line 1056), getSessionResponsePhaseSnapshot("before") (line 1088), and getSessionResponsePhaseSnapshot("after") (line 1095) — and surfaces them as distinct fields. Any reference scheme needs to keep these three reads individually resolvable so before/after can still be viewed separately when content genuinely differs.

3. Before-body asymmetry between stream and non-stream paths. In the streaming path, persistResponseBeforeSnapshot (src/app/v1/_lib/proxy/forwarder.ts:749-769) only persists headers and meta for the before phase — not body. The before-body key therefore typically only exists for non-streaming requests. A dedup design should not assume a before body is always present.

4. Reusable content-hash infrastructure exists. SessionManager already has a tenant-scoped content-hash pattern — buildTenantContentHashSessionKey(keyId, contentHash) (session-manager.ts:226-228) using SHA-256 truncated to 16 chars (calculateMessagesHash, session-manager.ts:536-548). A response-body dedup key (e.g. hash:{keyId}:{contentHash}:responseBody) could follow the same tenant-scoping and TTL model, giving the "single physical value per content" property this issue targets.

5. TTL consistency on overwrite/retry. All three keys currently use SESSION_TTL (default 300s). The acceptance criterion about "no dangling references, no erroneous reuse, TTL consistency" is the right focus — a reference scheme where the referenced value expires before its referrers (or vice versa) would produce the "body missing while headers/meta remain" state the compatibility boundary wants to avoid.

Scope confirmation

The stated invariants are all consistent with the current write/read code, so the dedup layer can be inserted between the redaction step and the setex calls without altering those contracts: STORE_SESSION_RESPONSE_BODY=false already fully skips writes (session-manager.ts:2058 and 2669), headers/meta are stored as separate keys, and none of these keys feed proxy response, token/cost stats, SSE detection, or Replay durable payloads.

---

Automated response from Claude AI