Messages and delivery
سیاست تلاش مجدد
اهداف
- تلاش دوباره برای هر درخواست HTTP، نه برای هر جریان چندمرحلهای.
- حفظ ترتیب با تلاش دوباره فقط برای گام فعلی.
- جلوگیری از تکرار عملیات غیرایدِمپوتنت.
پیشفرضها
- تعداد تلاشها: 3
- سقف بیشینه تأخیر: 30000 ms
- Jitter: 0.1 (10 درصد)
- پیشفرضهای ارائهدهنده:
- کمینه تأخیر Telegram: 400 ms
- کمینه تأخیر Discord: 500 ms
رفتار
ارائهدهندگان مدل
- OpenClaw اجازه میدهد SDKهای ارائهدهنده، تلاشهای دوباره کوتاه معمول را مدیریت کنند.
- برای SDKهای مبتنی بر Stainless مانند Anthropic و OpenAI، پاسخهای قابل تلاش دوباره
(
408،409،429، و5xx) میتوانند شاملretry-after-msیاretry-afterباشند. وقتی این انتظار طولانیتر از 60 ثانیه باشد، OpenClaw مقدارx-should-retry: falseرا تزریق میکند تا SDK خطا را بلافاصله نمایان کند و جایگزینی مدل بتواند به نمایه احراز هویت دیگر یا مدل پشتیبان بچرخد. - سقف را با
OPENCLAW_SDK_RETRY_MAX_WAIT_SECONDS=<seconds>بازنویسی کنید. آن را روی0،false،off،none، یاdisabledتنظیم کنید تا SDKها خوابهای طولانیRetry-Afterرا بهصورت داخلی رعایت کنند.
Discord
- در خطاهای محدودیت نرخ (HTTP 429)، مهلتگذشت درخواست، پاسخهای HTTP 5xx، و خرابیهای گذرای انتقال مانند خرابیهای جستوجوی DNS، بازنشانی اتصال، بستهشدن سوکت، و خرابیهای fetch دوباره تلاش میکند.
- وقتی
retry_afterدر دسترس باشد از آن استفاده میکند، در غیر این صورت از عقبنشینی نمایی استفاده میکند.
Telegram
- در خطاهای گذرا دوباره تلاش میکند (429، مهلتگذشت، اتصال/بازنشانی/بستهشده، موقتاً در دسترس نیست).
- وقتی
retry_afterدر دسترس باشد از آن استفاده میکند، در غیر این صورت از عقبنشینی نمایی استفاده میکند. - خطاهای تجزیه Markdown دوباره تلاش نمیشوند؛ آنها به متن ساده بازمیگردند.
پیکربندی
سیاست تلاش دوباره را برای هر ارائهدهنده در ~/.openclaw/openclaw.json تنظیم کنید:
{
channels: {
telegram: {
retry: {
attempts: 3,
minDelayMs: 400,
maxDelayMs: 30000,
jitter: 0.1,
},
},
discord: {
retry: {
attempts: 3,
minDelayMs: 500,
maxDelayMs: 30000,
jitter: 0.1,
},
},
},
}
یادداشتها
- تلاشهای دوباره برای هر درخواست اعمال میشوند (ارسال پیام، بارگذاری رسانه، واکنش، نظرسنجی، استیکر).
- جریانهای ترکیبی گامهای تکمیلشده را دوباره تلاش نمیکنند.