iomgaa
5b2e3ba82d
Twelve tasks across the two plans, each with the files it touches, the evidence it has to produce, and the command that proves it. #13 goes first: both branches edit config.py and client.py, and #12's partitioning template leans on the schema SQL helper and the untargeted conflict clause that #13 introduces. Writing the cap plan surfaced a trap worth its own guard. digest_messages appends the very same dict when a message's content is not a list, so the telemetry copy, the caller's messages and the cache key all share one object -- capping in place would poison the caller's request and the cache key at once, silently. Two red-line tests now pin that down, and the plan asks for an in-place version to be written and run first, to prove the tests actually catch it.
1.1 KiB
1.1 KiB
type, node_id, title, date
| type | node_id | title | date |
|---|---|---|---|
| plan | plan:plan-issue12-telemetry-retention | 实现计划: issue12-telemetry-retention | 2026-08-19 |
实现计划: issue12-telemetry-retention
正文: 2026-08-19-issue12-telemetry-retention.md。实现 design:issue12-telemetry-retention。
五个任务: ① 截断函数 + emitter text_cap 必填 + 三构造点; ② 配置与装配; ③ tools/telemetry_retention.py(默认 dry-run); ④ README 生产部署模板 + 其真实 PG 机械化验收; ⑤ CHANGELOG 与 wiki。
前置: issue #13 须先合并(两条分支都改 config.py/client.py,且分区模板依赖 #13 的 telemetry_schema_sql() 与无冲突目标写入)。
写计划时挖出的实现陷阱: digest_messages 对 content 非 list 的消息原样 append 同一个 dict,遥测拿到的与调用方传入的、缓存 key 用的是同一份对象——_cap_messages 若就地改,会同时污染调用方 messages、后续重试请求体与缓存写入 key,且全程无报错。计划已为此设两条红线用例,并要求先写一版就地改的实现证明红线能抓住它。