按请求重试
不是按整个聊天流程重拍一遍,而是只盯当前这一笔请求。
Concepts 导读
先看默认值:最多重试3次,最大延迟30秒,抖动10%。Discord仅在429时重试,Telegram重试更多错误但Markdown解析失败不重试。最容易搞错的是重试粒度——它只重试当前失败的HTTP请求,不会回退到流程开头。
先讲这一页到底在解决什么
先看默认值:最多重试3次,最大延迟30秒,抖动10%。Discord仅在429时重试,Telegram重试更多错误但Markdown解析失败不重试。最容易搞错的是重试粒度——它只重试当前失败的HTTP请求,不会回退到流程开头。
第一眼
这是 retry 的第一个关键点。它像一个小门童,专盯眼前这一敲。
不是按整个聊天流程重拍一遍,而是只盯当前这一笔请求。
因为只重试当前一步,所以不会把前面已经完成的动作顺手打乱。
像不会因为重试就把同一封信多寄几次。
比如发消息、上传媒体、加反应、发投票,每一步都各自看自己的重试规则。
第二站
默认值很像一个有礼貌的小门童:先试三次,别太急,也别无限闹腾。
像最多敲三下门。不是敲到天荒地老。
像告诉门童:等可以等,但最长别等到太离谱,最多三十秒封顶。
像每次重试的间隔不要太整齐,稍微抖一抖,避免大家都在同一秒一起撞门。
Telegram 和 Discord 的门口性格不一样,所以官方给了不同的最小延迟。
Discord
Discord 的规则很朴素:只在 rate limit 的时候重试。它不想把所有错误都当成“再来一次就好”。
像门口保安说“今天太挤了,等会儿再来”。这类才重试。
retry_after如果对方明确告诉你要等多久,就照着对方说的等,不自己乱猜。
像每次再敲门都稍微等久一点,别把门砸坏。
Discord 只在“太挤了”时再试,不是见错就重来。
Telegram
Telegram 的重试条件更宽。因为它常常会遇到网络抖一下、连接断一下、或者暂时不可用这种小麻烦。
像门口的灯刚闪了一下,或者传话线刚断了一秒。这些都可以再试。
像门口贴了一张“现在先别来,等会儿再说”的小纸条。
retry_after如果 Telegram 也给了你明确等待时间,就照它的话来。
这类不是门没开,而是你递过去的纸条格式坏了,所以它不会一遍遍重试同一张坏纸条,而是直接退回去改成纯文本。
attempts 像给小门童设最多敲几次;minDelayMs 像告诉它每次最少隔多久再敲;maxDelayMs 像封顶;jitter 像让节奏别太死板。
channels.telegram.retry像给 Telegram 单独放一张“重试怎么敲门”的小便签。
Telegram 允许更多暂时性问题重试,但坏格式不靠重试救。
重试是补救,不是重写规则。
第三站
这是官方特别强调的点。Composite flow 里,重试只发生在当前没做完的那一段,不会把已经成功的动作倒回去。
像只把坏掉的那一包重新拎起来,不会把前面已经送到家的包裹重送。
像砌墙砌到一半,坏的是这一块,不会把整面墙拆光重来。
处理顺序不会乱,不会因为重试把时间线倒着跑。
它是门口的补敲,不是整栋楼重建。
配置
官方给的 JSON 配置就是在说:Telegram 一套,Discord 一套,各写各的节奏。
channels.telegram.retry像给 Telegram 门口贴一张“如果卡住了怎么办”的说明。
channels.discord.retry像给 Discord 门口贴另一张不同节奏的说明。
attempts / minDelayMs / maxDelayMs / jitter分别像“最多试几次、最少等多久、最多等多久、每次别太整齐”。
重试是按门来设,不是整个系统一个大开关。
最后总结
Retry policy 就是一个有礼貌的小门童:遇到暂时性问题会再敲几次,但只敲当前这一步,不会把已经做完的事全部重来。
如果你愿意,我下一轮可以继续把剩下那批 `gateway` 和 `concepts` 页面也按同一标准收掉。