fix(memory): outbox 不再固化本进程猜测的 locale

[wehos]

#1542 收尾第 5 批。

问题

app/memory_server/routes.py 的四个写路由（/cache /process /renew /settle）把 _activate_request_language() 的返回值同时用于两处：

1. 包住本次请求的 language_context(memory_language)
2. 交给 _spawn_outbox_post_turn_signals(..., language=memory_language) 持久化进 outbox.ndjson

但这个返回值在请求未声明 locale 时是回落值 get_global_language_full() —— 本进程的探测结果。而 _spawn_outbox_post_turn_signals 里 if language: 恒真，于是这个「猜测」被写进 payload 永久冻结：重启后 replay 一直复用它，即使探测本身后来修好也不会自愈。

改动前（outbox 引入之前）replay 读的是当时的进程全局语言，探测修好后旧条目能跟着变。

改动

只持久化客户端真正声明的值：

• 四个调用点 language=memory_language → language=request.language
• memory_language 继续用于 language_context —— 本次请求内的回落是正确的，问题只在于不该落盘
• 未声明时 payload 不含 language 键，replay 走 language_context(None) 空转 → 回落当时的进程语言

进程内直跑路径不受影响：_spawn_outbox_post_turn_signals 在 with 块内调用，spawn 出的 task 会复制当前 context，仍然继承 memory_language。

关于测试（一个值得记录的返工）

第一版我只加了 _spawn_outbox_post_turn_signals 的契约测试（传 None 就不写 payload）。变异验证时把四个调用点全改回 memory_language，测试照样全绿 —— 因为它测的是那个函数自己的行为，证明不了路由真的传了 None。这正是「只测谓词不测调用点」。

补上之后是四条：

测试	守什么
test_cache_hands_outbox_the_undeclared_language_as_none	走真实 handler，断言未声明时交给 outbox 的是 None、声明了则原样透传
test_outbox_enqueue_persists_only_client_declared_language	AST 守卫，盯住四个调用点传的是 request.language 而非 memory_language
test_spawn_outbox_omits_language_when_request_declared_none	契约：传 None 不写 payload
test_replay_without_recorded_language_falls_back_to_process_locale	补上此前完全缺失的「存量 outbox 条目无 language 键」replay 覆盖 —— 这是升级用户唯一会走的路径

AST 守卫用自动发现（遍历四个 handler 找 _spawn_outbox_post_turn_signals 调用），漏掉任一调用点会直接断言失败，不是硬编码清单。

回归报告 / Regression Report

• 改动了什么：四个 memory 写路由交给 outbox 持久化的 locale，从「回落后的值」改为「客户端声明的原值」；补 4 条测试。
• 理由 / 必要性：把本进程的探测结果写进持久化队列，会让一次错误探测被永久固化，且 replay 无法自愈。
• 改动前后的表现对比：请求带 language 时行为完全不变（原值透传）。请求不带时，改动前 payload 会存入探测值，改动后不存该键 —— replay 回落到当时的进程语言，与 outbox 引入之前一致。当前 in-flight 请求的语言解析完全不变。
• 潜在回归点：(a) 若有调用方依赖「outbox 条目总是带 language 键」，改动后需处理缺键 —— _outbox_post_turn_signals_handler 本就用 payload.get('language')，已覆盖并新增测试；(b) 进程内直跑路径依赖 task 继承 context，已由既有的 test_concurrent_post_turn_tasks_keep_their_recorded_language 覆盖。
• 验证：变异验证 —— 把四处改回 memory_language 后行为测试与 AST 守卫立刻变红，还原后 17 passed；uv run pytest tests/unit -q → 6794 passed, 26 skipped, 0 failed。

不拆分理由 / Why Not Split

生产改动（4 个调用点 + 注释）与其守卫测试必须同 PR：调用点很容易在后续重构里被"顺手统一"回 memory_language，AST 守卫就是为此存在的。共 4 个文件、+151/-5。

[coderabbitai]

Warning

Review limit reached

You’ve reached a temporary PR review limit under our Fair Usage Limits Policy.

Your recent review volume is higher than typical usage, so adaptive limits are currently applied.

Next review available in: 31 minutes

Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available.
You're only billed for reviews past your plan's rate limits ($0.25/file).

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 5c6c3a04-69b7-433b-b2e5-2fbea774473e

📥 Commits

Reviewing files that changed from the base of the PR and between 92ed281 and a80210e.

📒 Files selected for processing (4)

• app/memory_server/post_turn.py
• app/memory_server/routes.py
• tests/unit/test_memory_request_language_context.py
• tests/unit/test_outbox_wiring.py

---

_{Comment @coderabbitai help to get the list of available commands.}

[greptile-apps]

Greptile Summary

四个 memory 写路由现在仅将客户端明确声明的 locale 持久化到 outbox，同时保留当前请求的 locale 回落行为喵。

• /cache、/process、/renew 与 /settle 将 request.language 传给 outbox，避免固化进程推测值喵。
• 未记录 locale 的 outbox 条目在 replay 时继续回落到当时的进程语言喵。
• 新增真实 handler、调用点、payload 契约与旧条目 replay 测试喵。

Confidence Score: 5/5

此 PR 未发现阻塞或非阻塞问题，看起来可以安全合并喵。

显式 locale 在 replay 时仍由 language context 正常校验和规范化，缺省或不受支持的值则安全回落到进程语言，新增测试也覆盖了四个调用点及存量条目路径喵。

Important Files Changed

Filename	Overview
app/memory_server/routes.py	四个写路由改为向 outbox 传递客户端原始声明值，同时继续使用解析后的 locale 处理当前请求喵。
app/memory_server/post_turn.py	补充注释，明确持久化声明 locale 与当前请求回落 locale 的边界喵。
tests/unit/test_memory_request_language_context.py	新增 handler 行为与四个调用点的回归守卫，确保未声明 locale 不会被替换后落盘喵。
tests/unit/test_outbox_wiring.py	覆盖缺省 locale 的 payload 省略行为以及旧 outbox 条目的 replay 回落路径喵。

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart LR
    A[Memory write request] --> B{Client declared language?}
    B -->|Yes| C[Persist declared language in outbox]
    B -->|No| D[Omit language from outbox payload]
    C --> E[Replay under recorded language context]
    D --> F[Replay under current process locale]
    A --> G[Resolve request locale with process fallback]
    G --> H[Handle current request under resolved context]

Loading

_{Reviews (1): Last reviewed commit: "fix(memory): outbox 不再固化本进程猜测的 locale" | Re-trigger Greptile}