---
read_when:
    - به‌روزرسانی رفتار یا مقادیر پیش‌فرض تلاش مجدد ارائه‌دهنده
    - اشکال‌زدایی خطاهای ارسال ارائه‌دهنده یا محدودیت‌های نرخ درخواست
summary: سیاست تلاش مجدد برای فراخوانی‌های خروجی ارائه‌دهنده
title: سیاست تلاش مجدد
x-i18n:
    generated_at: "2026-07-12T10:01:08Z"
    model: gpt-5.6
    postprocess_version: locale-links-v1
    provider: openai
    source_hash: 9be2bcb5af829b90042bfcbc5c0e5f5cc5a3cb03dd5472737c80fa0f15803361
    source_path: concepts/retry.md
    workflow: 16
---

## اهداف

- تلاش مجدد برای هر درخواست HTTP انجام شود، نه برای کل جریان چندمرحله‌ای.
- با تلاش مجدد فقط برای مرحلهٔ جاری، ترتیب حفظ شود.
- از تکرار عملیات غیرایدِمپوتنت جلوگیری شود.

## مقادیر پیش‌فرض

| تنظیم                    | مقدار پیش‌فرض |
| ------------------------ | ------------- |
| تعداد تلاش‌ها            | 3             |
| سقف حداکثر تأخیر         | 30000 ms      |
| نوسان تصادفی             | 0.1 (10%)     |
| حداقل تأخیر Telegram     | 400 ms        |
| حداقل تأخیر Discord      | 500 ms        |

## رفتار

### ارائه‌دهندگان مدل

- OpenClaw مدیریت تلاش‌های مجدد کوتاه و معمول را به SDKهای ارائه‌دهندگان واگذار می‌کند.
- در SDKهای مبتنی بر Stainless، مانند Anthropic و OpenAI، پاسخ‌های قابل تلاش مجدد (`408`، `409`، `429` و `5xx`) می‌توانند شامل `retry-after-ms` یا `retry-after` باشند. هنگامی که این زمان انتظار بیشتر از ۶۰ ثانیه باشد، OpenClaw سرآیند `x-should-retry: false` را اضافه می‌کند تا SDK خطا را فوراً برگرداند و سازوکار جایگزینی مدل بتواند به نمایهٔ احراز هویت دیگری یا مدل پشتیبان منتقل شود.
- برای بازنویسی این سقف، از `OPENCLAW_SDK_RETRY_MAX_WAIT_SECONDS=<seconds>` استفاده کنید. برای اینکه SDKها زمان‌های انتظار طولانی `Retry-After` را به‌صورت داخلی رعایت کنند، آن را روی `0`، `false`، `off`، `none` یا `disabled` تنظیم کنید.

### Discord

- در خطاهای محدودیت نرخ (HTTP 429)، پایان مهلت درخواست، پاسخ‌های HTTP 5xx و اختلال‌های گذرای انتقال مانند شکست جست‌وجوی DNS، بازنشانی اتصال، بسته‌شدن سوکت و شکست واکشی، تلاش مجدد انجام می‌دهد.
- در صورت وجود، از `retry_after` متعلق به Discord استفاده می‌کند؛ در غیر این صورت، از پس‌روی نمایی بهره می‌گیرد.

### Telegram

- در خطاهای گذرا (429، پایان مهلت، اتصال/بازنشانی/بسته‌شدن و دردسترس‌نبودن موقت) تلاش مجدد انجام می‌دهد.
- در صورت وجود، از `retry_after` استفاده می‌کند؛ در غیر این صورت، از پس‌روی نمایی بهره می‌گیرد.
- برای خطاهای تجزیهٔ HTML/Markdown تلاش مجدد انجام نمی‌شود؛ در نخستین تلاش، به متن ساده بازمی‌گردند.

## پیکربندی

سیاست تلاش مجدد هر ارائه‌دهنده را در `~/.openclaw/openclaw.json` تنظیم کنید:

```json5
{
  channels: {
    telegram: {
      retry: {
        attempts: 3,
        minDelayMs: 400,
        maxDelayMs: 30000,
        jitter: 0.1,
      },
    },
    discord: {
      retry: {
        attempts: 3,
        minDelayMs: 500,
        maxDelayMs: 30000,
        jitter: 0.1,
      },
    },
  },
}
```

## نکات

- تلاش‌های مجدد برای هر درخواست به‌طور جداگانه اعمال می‌شوند (ارسال پیام، بارگذاری رسانه، واکنش، نظرسنجی، برچسب).
- جریان‌های ترکیبی مراحل تکمیل‌شده را دوباره اجرا نمی‌کنند.

## مرتبط

- [جایگزینی مدل](/fa/concepts/model-failover)
- [صف فرمان](/fa/concepts/queue)