fix: check the meta key budget before scanning every key

The key-count cap exists to catch a whole request body dumped into meta.
That is exactly the shape where the per-key regex runs tens of thousands
of times before the real reason surfaces, so the cheap check goes first.

Also correct two stale docstrings: postgres.py still claimed 22 columns
(it is 24), and _canonical_meta_json promised to raise on non-finite
floats. It is evaluated inside _record's degradation try, so the real
outcome is a warning plus a dropped row -- never an error the caller
sees. What the gate actually buys us is the SQLite side, whose meta is a
TEXT column that would happily store a literal NaN.
This commit is contained in:
2026-08-17 12:26:37 -04:00
parent 25cb0a6e0c
commit 9bdd312928
3 changed files with 12 additions and 5 deletions
+7 -2
View File
@@ -42,8 +42,13 @@ def _canonical_meta_json(meta: Mapping[str, Any]) -> str:
`allow_nan=False` 是**第二道闸**(主防线是 `types.validate_caller_dimensions` `allow_nan=False` 是**第二道闸**(主防线是 `types.validate_caller_dimensions`
在公共入口的校验): `json.dumps` 默认把 `nan` 写成裸 `NaN` 字面量,那不是合法 在公共入口的校验): `json.dumps` 默认把 `nan` 写成裸 `NaN` 字面量,那不是合法
JSON,PG 的 JSONB 会拒收;而写入失败会被 `_record` 的降级 try 吞成 warning, JSON。这道闸真正的价值在 **SQLite 侧**——PG 的 JSONB 本来就会拒收 `NaN`,而
等于把调用方的输入错误转化成静默丢遥测。宁可在这里显式抛。 SQLite 的 `meta` 是 TEXT 列**不做任何 JSON 校验**,没有这道闸就会把 `NaN`
这种非法 JSON 静默存进去,污染后续一切按 JSON 解析 meta 的分析。
注意它抛出的 `ValueError` **不会外泄给调用方**: 本函数在 `_record` 的降级
`try` 内被求值,异常会被那里的 `except Exception` 接住 → 落 warning、整行
遥测丢弃。即入口失守时的真实结果是"警告 + 丢一行",不是"报错给调用方"
""" """
if not meta: if not meta:
return "{}" return "{}"
+1 -1
View File
@@ -6,7 +6,7 @@
① 结构性失败 → warning 一次后永久降级(所有写入短路); ① 结构性失败 → warning 一次后永久降级(所有写入短路);
② 运行时单条写失败 → 逐条 warning 丢弃,不降级不重试(连接抖动由 ② 运行时单条写失败 → 逐条 warning 丢弃,不降级不重试(连接抖动由
asyncpg 池自恢复;避免浸泡开头一次抖动导致后续全程失遥测)。 asyncpg 池自恢复;避免浸泡开头一次抖动导致后续全程失遥测)。
构造不连库(lazy),22 列 schema 与 SQLite 版同名同序。 构造不连库(lazy),24 列 schema 与 SQLite 版同名同序。
**"结构性"的判据是「确定写不进去」,不是「初始化时出过错」**(issue #9): **"结构性"的判据是「确定写不进去」,不是「初始化时出过错」**(issue #9):
只有建池失败(重试要在业务路径上内联吞掉 connect 超时)与"表确定不存在 只有建池失败(重试要在业务路径上内联吞掉 connect 超时)与"表确定不存在
+4 -2
View File
@@ -115,6 +115,10 @@ def _validate_tenant_id(tenant_id: str | None, origin: str) -> None:
def _validate_meta_keys(meta: Mapping[str, Any], origin: str) -> None: def _validate_meta_keys(meta: Mapping[str, Any], origin: str) -> None:
"""键形态与数量;键集合被假定为低基数且稳定,故收紧到 OTel semconv 字符集。""" """键形态与数量;键集合被假定为低基数且稳定,故收紧到 OTel semconv 字符集。"""
# 数量闸先于逐键校验: 这道闸要防的正是"整个请求体被塞进 meta"的形态,
# 那时逐键正则会先跑上万次才报出真正的原因,拖慢的恰是出错路径
if len(meta) > _META_MAX_KEYS:
raise ValueError(f"{origin} 的 meta 键数超限(上限 {_META_MAX_KEYS}): {len(meta)}")
for key in meta: for key in meta:
if not isinstance(key, str): if not isinstance(key, str):
raise ValueError(f"{origin} 的 meta 键必须是 str: {key!r}") raise ValueError(f"{origin} 的 meta 键必须是 str: {key!r}")
@@ -127,8 +131,6 @@ def _validate_meta_keys(meta: Mapping[str, Any], origin: str) -> None:
raise ValueError( raise ValueError(
f"{origin} 的 meta 键 {key!r} 不合法: 只允许小写字母/数字/下划线/点,长度 1-64" f"{origin} 的 meta 键 {key!r} 不合法: 只允许小写字母/数字/下划线/点,长度 1-64"
) )
if len(meta) > _META_MAX_KEYS:
raise ValueError(f"{origin} 的 meta 键数超限(上限 {_META_MAX_KEYS}): {len(meta)}")
def _validate_meta_values(meta: Mapping[str, Any], origin: str) -> None: def _validate_meta_values(meta: Mapping[str, Any], origin: str) -> None: