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.
18 lines
1.1 KiB
Markdown
18 lines
1.1 KiB
Markdown
---
|
|
type: plan
|
|
node_id: plan:plan-issue12-telemetry-retention
|
|
title: "实现计划: issue12-telemetry-retention"
|
|
date: 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,且全程无报错。计划已为此设两条红线用例,并要求先写一版就地改的实现证明红线能抓住它。
|