Repository navigation
v0.9.21
AutoBuddy v0.9.21
修正 v0.9.20 日志去重的两个缺陷:重复次数被悄悄吞掉、去重字典无上限。
背景
v0.9.20 上线后我做了一次部署后对照实测,发现去重虽然生效,
但有两个我自己引入的缺陷。
缺陷 1:重复次数被悄悄吞掉(观测断档)
原设计
「内容变化时,先汇报上一条被吞了多少次」:
repeat = _ACCESS_DEDUP_COUNT.get(key, 0)
if repeat > 0:
print(f"(上一条重复 {repeat} 次) {key}")为什么永远不会触发
为了抗交错轮询(A、B 交替),去重是按内容各自独立记录的:
c3 累积的次数 → 记在 c3 名下
d4 出现时 → 查的是 d4 的计数(= 0)
所以那行交代永远不会打印。
实测确认
| 场景 | 结果 | 判定 |
|---|---|---|
| 发 3 个不同内容 | 出现 3 行 | ✅ 没被静音 |
| 再发 4 次相同内容 | 0 行 | ✅ 去重生效 |
| 换成新内容 | 只出现新行,无交代行 | ❌ 观测断档 |
修复
改为按时间周期汇报:默认每 60s 把各条内容累积的待报次数
统一打出并清零。
INFO: (重复 N 次) <内容>
可用环境变量 ACCESS_DEDUP_FLUSH_SEC 调整周期(测试时可设成几秒)。
这样既保留可观测性,又不破坏「按内容各自去重」的正确性。
缺陷 2:去重字典无上限(内存泄漏)
_ACCESS_DEDUP_LAST 每遇到一种新内容就加一个键,从不清理。
access log 的内容种类理论上无界 —— URL 里带动态 id 时尤甚 ——
长时间运行就是一条缓慢的内存泄漏。
现已加上限 _ACCESS_DEDUP_MAX_KEYS = 500,超出时淘汰最早写入的键
(dict 保持插入顺序,取前 N 个即可)。
回归测试补强
_test_log_dedup.py 新增两条校验:
- 必须存在
_flush_access_dedup(否则重复次数被悄悄吞掉) - 必须存在容量上限(否则内存泄漏)
这两条都是实测踩出来的,不是凭空加的。
验证
四模块 AST ✅ 通过
15 项单元测试 ✅ 全绿(含新增两条校验)
版本一致性自检 ✅ 通过
部署后对照实测 ✅ 去重生效 + 不同内容不误杀
升级说明
重建容器即可,/data 数据不受影响。
- 新增可选环境变量
ACCESS_DEDUP_FLUSH_SEC(默认 60,不设即用默认值); - 无数据库结构变更;
- 本次为日志输出层调整,不影响任何接口行为。