Messages and delivery
سياسة إعادة المحاولة
الأهداف
- إعادة المحاولة لكل طلب HTTP، وليس لكل تدفق متعدد الخطوات.
- الحفاظ على الترتيب عبر إعادة محاولة الخطوة الحالية فقط.
- تجنب تكرار العمليات غير الآمنة للتكرار.
الإعدادات الافتراضية
- المحاولات: 3
- الحد الأقصى للتأخير: 30000 مللي ثانية
- التذبذب: 0.1 (10 بالمئة)
- إعدادات المزوّدين الافتراضية:
- الحد الأدنى لتأخير Telegram: 400 مللي ثانية
- الحد الأدنى لتأخير Discord: 500 مللي ثانية
السلوك
مزوّدو النماذج
- يتيح OpenClaw لحِزم SDK الخاصة بالمزوّدين التعامل مع عمليات إعادة المحاولة القصيرة العادية.
- بالنسبة إلى حِزم SDK المبنية على Stainless مثل Anthropic وOpenAI، يمكن أن تتضمن الاستجابات القابلة لإعادة المحاولة
(
408و409و429و5xx)retry-after-msأوretry-after. عندما يكون وقت الانتظار هذا أطول من 60 ثانية، يحقن OpenClawx-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، وإعادة ضبط الاتصال، وإغلاق المقابس، وفشل الجلب.
- يستخدم
retry_afterالخاص بـ Discord عند توفره، وإلا فيستخدم التراجع الأسي.
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,
},
},
},
}
ملاحظات
- تنطبق عمليات إعادة المحاولة لكل طلب (إرسال رسالة، رفع وسائط، تفاعل، استطلاع، ملصق).
- لا تعيد التدفقات المركبة محاولة الخطوات المكتملة.