ပြန်လည်ကြိုးစားမှု မူဝါဒ¶

ရည်ရွယ်ချက်များ¶

• Multi-step flow တစ်ခုလုံးအလိုက် မဟုတ်ဘဲ HTTP request တစ်ခုချင်းစီအလိုက် ပြန်လည်ကြိုးစားရန်။
• လက်ရှိ အဆင့်ကိုသာ ပြန်လည်ကြိုးစားခြင်းဖြင့် အစီအစဉ်တကျဖြစ်မှုကို ထိန်းသိမ်းရန်။
• Idempotent မဟုတ်သော လုပ်ဆောင်ချက်များကို ထပ်မံလုပ်ဆောင်မိခြင်းကို ရှောင်ရှားရန်။

ပုံသေတန်ဖိုးများ¶

• ကြိုးစားမှု အကြိမ်ရေ: 3
• အမြင့်ဆုံး နှောင့်နှေးချိန် ကန့်သတ်ချက်: 30000 ms
• Jitter: 0.1 (10 ရာခိုင်နှုန်း)
• Provider ပုံသေတန်ဖိုးများ:
• Telegram အနည်းဆုံး နှောင့်နှေးချိန်: 400 ms
• Discord အနည်းဆုံး နှောင့်နှေးချိန်: 500 ms

အပြုအမူ¶

Discord¶

• Rate-limit အမှားများ (HTTP 429) တွင်သာ ပြန်လည်ကြိုးစားသည်။
• ရရှိနိုင်ပါက Discord retry_after ကို အသုံးပြုသည်၊ မရရှိပါက exponential backoff ကို အသုံးပြုသည်။

Telegram¶

• အချိန်ပိုင်းဆိုင်ရာ အမှားများ (429, timeout, connect/reset/closed, temporarily unavailable) တွင် ပြန်လည်ကြိုးစားသည်။
• ရရှိနိုင်ပါက retry_after ကို အသုံးပြုသည်၊ မရရှိပါက exponential backoff ကို အသုံးပြုသည်။
• Markdown parse အမှားများကို ပြန်လည်ကြိုးစားမည်မဟုတ်ပါ; plain text သို့ fallback လုပ်သည်။

ဖွဲ့စည်းပြင်ဆင်ခြင်း¶

Provider တစ်ခုချင်းစီအလိုက် retry မူဝါဒကို ~/.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,
      },
    },
  },
}

မှတ်ချက်များ¶

• Retry များကို request တစ်ခုချင်းစီအလိုက် (မက်ဆေ့ချ်ပို့ခြင်း၊ မီဒီယာတင်ခြင်း၊ reaction၊ poll၊ sticker) အသုံးပြုသည်။
• Composite flows များတွင် ပြီးစီးပြီးသား အဆင့်များကို ပြန်လည်ကြိုးစားမည်မဟုတ်ပါ။