PolyGateway

iomgaa/PolyGateway

Fork 0

Commit Graph

Author	SHA1	Message	Date
iomgaa	6d6b3cf59c	docs: correct the stale throughput numbers and wiki state 独立验证发现的 3 处文档欠账: ③ 两处代码内注释还挂着已作废的吞吐估算,`.env.example`/README/ CHANGELOG/ARCHITECTURE 四处早已改成实测口径: - `config.py` 的 `# 4 条 ≈ 32 行/秒(实测…)` —— "32 行/秒"正是设计 §10 修订 #1 判定"偏乐观一倍"并作废的估算值,却挂着"实测"二字; - `postgres.py` 的 `pool_max` docstring 写着 `稳态吞吐 ≈ pool_max / RTT`,正是设计要求下游不要用的那个公式。两处统一为实测值: RTT ≈ 123ms 上 `pool_max=4` 约 15.6 行/秒 (50 行并发批 3.2s)。设计 §8 与计划 T7 里残留的同一公式一并标注作废。 ④ 文档写 `acquire(timeout=剩余预算)`,实现传的是完整预算(行为无害, 外层 `asyncio.timeout` 才是真正上界)。改文档不改代码: 设计 §3.1、计划 T3、ARCH §7.8 三处对齐,并写明为什么内层不再算剩余量。 ⑤ wiki 登记页与正文状态漂移: design 登记页仍写"待人类审"(正文已是 "已实施")、plan 登记页写"正文 326 行"(实际 380)、log.md 末条停在 T0 之前。三处校正,T1-T8 补登记,rebuild_index。另补一条独立验证在真实 PG 上发现的语义细节: 本地池饱和造成的丢行走行级丢弃,`degraded` 保持 False,只有 `dropped_rows` 增长——只按 `degraded` 配告警的下游会完全看不见这类丢行,而它恰是 `pool_max` 配小了的唯一信号。README / .env.example / ARCHITECTURE / CHANGELOG 各补一句。	2026-08-24 11:55:22 -04:00
iomgaa	e7caa500e2	docs: plan the telemetry pool lifecycle rework for issue 15 The design traces the incident to four stacked defects rather than one bad default: the pool is the only resource in the library that pre-allocates, the kill switch keys off which step failed instead of what failed, the degraded state can neither recover nor be observed, and the ownership rules make the sanctioned sharing path unusable. The plan sequences the tracker ahead of the pool and failure work so every commit stays green, and records two facts the implementer needs up front: the pool-construction path has zero test coverage today, and the commit gate runs the full suite plus a complexity ceiling.	2026-08-24 08:17:37 -04:00

Author

SHA1

Message

Date

iomgaa

6d6b3cf59c

docs: correct the stale throughput numbers and wiki state

独立验证发现的 3 处文档欠账:

③ 两处代码内注释还挂着已作废的吞吐估算,`.env.example`/README/
   CHANGELOG/ARCHITECTURE 四处早已改成实测口径:
   - `config.py` 的 `# 4 条 ≈ 32 行/秒(实测…)` —— "32 行/秒"正是设计
     §10 修订 #1 判定"偏乐观一倍"并作废的估算值,却挂着"实测"二字;
   - `postgres.py` 的 `pool_max` docstring 写着 `稳态吞吐 ≈ pool_max /
     RTT`,正是设计要求下游**不要**用的那个公式。
   两处统一为实测值: RTT ≈ 123ms 上 `pool_max=4` 约 15.6 行/秒
   (50 行并发批 3.2s)。设计 §8 与计划 T7 里残留的同一公式一并标注作废。

④ 文档写 `acquire(timeout=剩余预算)`,实现传的是完整预算(行为无害,
   外层 `asyncio.timeout` 才是真正上界)。**改文档不改代码**: 设计
   §3.1、计划 T3、ARCH §7.8 三处对齐,并写明为什么内层不再算剩余量。

⑤ wiki 登记页与正文状态漂移: design 登记页仍写"待人类审"(正文已是
   "已实施")、plan 登记页写"正文 326 行"(实际 380)、log.md 末条停在
   T0 之前。三处校正,T1-T8 补登记,rebuild_index。

另补一条独立验证在真实 PG 上发现的语义细节: 本地池饱和造成的丢行走
**行级丢弃**,`degraded` 保持 False,只有 `dropped_rows` 增长——只按
`degraded` 配告警的下游会完全看不见这类丢行,而它恰是 `pool_max` 配小
了的唯一信号。README / .env.example / ARCHITECTURE / CHANGELOG 各补一句。

2026-08-24 11:55:22 -04:00

iomgaa

e7caa500e2

docs: plan the telemetry pool lifecycle rework for issue 15

The design traces the incident to four stacked defects rather than one bad
default: the pool is the only resource in the library that pre-allocates,
the kill switch keys off which step failed instead of what failed, the
degraded state can neither recover nor be observed, and the ownership rules
make the sanctioned sharing path unusable.

The plan sequences the tracker ahead of the pool and failure work so every
commit stays green, and records two facts the implementer needs up front:
the pool-construction path has zero test coverage today, and the commit
gate runs the full suite plus a complexity ceiling.

2026-08-24 08:17:37 -04:00

2 Commits