iomgaa
bf2fbd6c5e
OcrClient emits through the same helper and its rows land in the same table as chat rows. Covering only chat and embed would leave one table holding rows that have a tenant and rows that never will, and the issue's own irreversibility argument applies to those rows too. The design said two paths because the issue said two paths. Corrected at the source rather than only in the plan, so a later reader does not find OCR work with no design behind it.
2.0 KiB
2.0 KiB
type, node_id, title, date
| type | node_id | title | date |
|---|---|---|---|
| plan | plan:issue11-caller-dimensions | 调用方自定义维度实现计划(issue #11) | 2026-08-17 |
调用方自定义维度实现计划(issue #11)
正文: 2026-08-17-issue11-caller-dimensions.md(269 行,8 个任务)。实现 design:issue11-caller-dimensions。
- 任务顺序: 端口与两个遥测后端(Task 2)先于三条调用链(Task 4/5/6)落地——后者写入的字段必须已有列可落。Task 1(校验函数 +
ChatRequest字段)是全部任务的前置。 - 计划阶段的新发现: 设计只覆盖
chat()/embed(),核实代码发现第三条遥测链路——OcrClient经同一TelemetryEmitter.emit_attempt写遥测(ocr.py:426),_emit在ocr.py:398现场构造ChatRequest,与 embedding 同构。OCR 行与 chat 行落同一张表,漏掉则多租户审计链缺一块且同样不可逆。列为 Task 6,人类已追认纳入正式范围(设计 §1.2 同步补正)(与 issue #10 先例一致: 那次 issue 只报告 chat 的 400,OCR 被认定为同一缺陷的其余分支而一并修),是必做项。 - 把 issue 的核心论点钉成测试: Task 7 要求手工建 22 列旧表 → 用当前 recorder 打开 → 断言老行
tenant_id读回空串而非 NULL。这直接验收 issue「先启用后加列则归属无法还原」的论点,且断言方向选空串是因为 NULL 在 RLS policy 下是对所有人永久不可见的黑洞,而非"未归属"。 - 几处易实现反的地方已写进验收:
emit_cache_hit必须读本次请求的维度而非缓存中历史响应的(构造"请求属租户 A、缓存历史属租户 B"的用例断言落 A);embed()多批时每一批的行都要带同一份维度(只断言首行会漏掉"只有第一批带维度"的实现);非法输入必须ValueError且 recorder 零调用(证明校验早于遥测)。 - 不做的事: 不把 embedding/OCR 链上已有的四个同类参数收成值对象(任务外重构);不建索引、不启用 RLS(库只交付模板,执行是下游 DBA 职责)。