Files
ARTEX/server
Autumn-27 93c1d39df3 fix(notify): 汇总模式按消息计量限流,批次大小不再被每轮请求预算掐死
令牌桶的额度此前被同时当成两个量纲用:对实时模式它是「发几条消息」,
对汇总模式却被直接当成「一批装几条漏洞」传给 ClaimDigestBatch。

notifyMaxSendsPerChannelPerTick(=5)是由租约时长倒推的 HTTP 请求预算,
而一个汇总批次只发一次请求,两者本不该相乘。稳态下更糟:rate_per_min=20
的渠道在 3 秒的 tick 里只补得到 1 个令牌,于是每条汇总消息只装 1 个漏洞,
头部还写着「近 30 分钟新增 1 个漏洞」——digest 退化成带汇总文案的实时推送,
MaxDigestBatchSize(500) 永不可达。

改为统一按**消息条数**计量:一批漏洞合成一条消息、消耗一个令牌,
rate_per_min 对 digest 依然生效(每分钟最多这么多条汇总消息),
而批次大小只受 MaxDigestBatchSize 这个内存上界约束。

ClaimDigestBatch 原先的注释声称「单批同时受限流额度与内存上界约束」,
那正是本问题的来源——限流额度本不该充当批次大小。注释一并改掉,
免得下次又按「rate_per_min 对 digest 不生效」把它改回去。

顺带让 takeTokens 接受 want 上限:原先整桶抽空后才由调用方截断,
多出来的令牌(飞书默认 100/min 时是 95 个)直接丢弃,渠道这一轮
没有待发投递时也照扣,注释声称的突发容量在任何情况下都做不到。

决策收在 digestTickPlan 里由新增用例直接钉住。现有端到端用例都手动给
stepDigest 传一个够大的 limit,绕过了 step 里的额度计算,所以覆盖不到这里。
2026-10-01 06:43:29 -04:00
..
2026-07-26 04:27:45 -04:00
2026-07-26 04:27:45 -04:00
2026-08-24 14:14:15 +08:00
2026-08-28 12:56:29 +08:00
2026-08-24 14:14:15 +08:00
2026-07-26 04:27:45 -04:00
2026-07-26 04:27:45 -04:00
2026-08-24 14:14:15 +08:00
2026-08-24 14:14:15 +08:00
2026-08-28 12:56:29 +08:00
2026-08-24 14:14:15 +08:00
2026-07-26 04:27:45 -04:00
2026-08-25 12:05:26 +08:00
2026-08-25 12:05:26 +08:00
2026-07-26 04:27:45 -04:00
2026-07-26 04:27:45 -04:00
2026-07-26 04:27:45 -04:00