Timeout နှင့် Retry

နားလည်ထားရမယ့် အချက်

Request တစ်ခုက နောက်ဆုံး status code ပါတဲ့ response တစ်ခု ရမယ်ဆိုတာ သင် သိပြီးသားပါ။ API Tutorial က မဖော်ပြခဲ့တာက response လုံးဝ မလာဘူးဆိုရင် ဘာဖြစ်လဲဆိုတာပါ။

Connection တစ်ခု hang ဖြစ်ခြင်း၊ server overload ဖြစ်ခြင်း၊ network packet ကျဆုံးခြင်းတို့က client-side timeout ကို မသတ်မှတ်ထားရင် သင့် code ကို အဆုံးမရှိ စောင့်စေနိုင်ပါတယ် — timeout ဆိုတာ server ဆက်လုပ်နေသေးရင်တောင် request ကို လက်လွှတ်ပြီး failed အဖြစ် သတ်မှတ်ရမယ့် အချိန်ကန့်သတ်ချက်ပါ။

Request fail သွားပြီဆိုရင် နောက်ဆုံးဆုံးဖြတ်ချက်က retry လုပ်မလားဆိုတာပါ၊ မမြင်ဘဲ retry လုပ်ခြင်းက အမှားတစ်ခုပါ။ 4xx client error — malformed request body (သို့) invalid resource ID လိုမျိုး — က ဘယ်နှစ်ကြိမ် ပြန်ပို့ပို့ ထပ်တူ fail နေဦးမှာပါ၊ ပြဿနာက network ထဲမှာ မဟုတ်ဘဲ ပို့လိုက်တဲ့ content ထဲမှာ ရှိလို့ပါ။

• Temporary server failure (5xx status code)
• Network-level failure — connection ပြတ်တောက်ခြင်းလိုမျိုး
• 429 rate-limit response — provider ရဲ့ documentation က retry ကို မျှော်လင့်ထားပါက အထူးသဖြင့်

Retry လုပ်တဲ့အခါ attempt တွေကြား ကြားကာလကို ဘယ်လို ချထားလဲဆိုတာလည်း အရေးကြီးပါတယ်။ Exponential backoff က attempt တစ်ခုစီကြား စောင့်ချိန်ကို နှစ်ဆတိုးပေးလို့ millisecond အနည်းငယ်တိုင်း struggle နေတဲ့ server ကို ထပ်ခါထပ်ခါ hit မလုပ်တော့ပါဘူး။

Jitter ကတော့ အဲဒီ delay ပေါ် random offset အနည်းငယ် ထပ်ထည့်ပေးလို့ failure တစ်ခုတည်းကို retry နေကြတဲ့ client အများကြီးက အချိန်တစ်ခုတည်းမှာ တစ်ပြိုင်နက် retry လုပ်ပြီး overload wave အသစ်တစ်ခု မဖြစ်စေအောင် ကာကွယ်ပေးပါတယ်။ Backoff နဲ့ jitter ပေါင်းလိုက်ရင် naive retry loop တစ်ခုကို real failure condition အောက်မှာ တာဝန်သိစွာ ကျင့်ဆောင်တတ်တဲ့ loop တစ်ခု ဖြစ်လာစေပါတယ်။

Timeout

Server (သို့) network တစ်ခုက အချိန်မီ မတုံ့ပြန်ရင် client က request ကို လက်လွှတ်ပြီး failed အဖြစ် သတ်မှတ်ရမယ့် hard time limit တစ်ခု။

Backoff

Retry attempt တစ်ခုစီကြား စောင့်ချိန်ကို တိုးမြှင့်ပေးတဲ့ strategy — exponential backoff မှာ delay က attempt တိုင်း နှစ်ဆ ဖြစ်လာတယ်။

EXPONENTIAL BACKOFF SEQUENCE
----------------------------
ATTEMPT 1 (t=0s)     FAIL
   |
   | wait 1s
   v
ATTEMPT 2 (t=1s)     FAIL
   |
   | wait 2s
   v
ATTEMPT 3 (t=3s)     FAIL
   |
   | wait 4s
   v
ATTEMPT 4 (t=7s)     SUCCESS

Delay doubles each time: 1s -> 2s -> 4s (exponential backoff)

လက်တွေ့ scenario နဲ့ ချိတ်ကြည့်မယ်

အောက်က function က client တစ်ခု request ကို retry လုပ်နေတာကို fixed, pre-scripted outcome sequence, `["fail", "fail", "fail", "success"]` အပေါ် simulate လုပ်ထားတာပါ၊ real network call ဘာမှ မလုပ်ပါဘူး။ ဒါက ဥပမာကို completely deterministic ဖြစ်စေပါတယ်။

ပထမဆုံး attempt ပြီးနောက် attempt တစ်ခုစီအတွက် delay က နှစ်ဆ ဖြစ်လာပါတယ် — 1000ms, 2000ms, 4000ms — classic `baseDelay * 2^(attempt - 2)` formula ကို လိုက်နာပါတယ်။ Loop က `"success"` outcome ကို မှတ်တမ်းတင်ပြီးတာနဲ့ ရပ်သွားပါတယ်။

Production code မှာဆိုရင် ဒီ delay အပေါ် jitter ထပ်ထည့်ရမှာဖြစ်ပြီး number ကို မှတ်တမ်းတင်ရုံမက timer တစ်ခုကို တကယ် `await` လုပ်ရမှာပါ၊ ဒါပေမယ့် retry-and-backoff logic ကိုယ်တိုင်ကတော့ real SDK တွေထဲမှာ ပါလာတာနဲ့ တူညီပါတယ်။

Output ကို case study အသေးလေးအနေနဲ့ ဖတ်ကြည့်ပါ — အဆက်တိုက် failure သုံးကြိမ်က naive retry-every-100ms loop ကို struggle နေတဲ့ server ပေါ် overload ဖြစ်စေနိုင်ပါတယ်၊ ဒါပေမယ့် ဒီ schedule ကတော့ attempt လေးခုတည်းကို wall-clock time စက္ကန့် ခုနစ်ဆယ်ခန့်အထိ ဖြန့်ကျက်ပေးလို့ server ကို ပြန်လည်ကောင်းမွန်စေဖို့ အချိန်အစစ် ပေးထားပါတယ်။

• Client-side timeout မရှိရင် request တစ်ခု အဆုံးမရှိ စောင့်နေနိုင်တယ်
• 4xx error ကို retry မလုပ်ပါနဲ့ — 5xx, network failure, 429 ကိုပဲ retry ထိုက်တယ်
• Exponential backoff + jitter က retry loop တွေကို responsible ဖြစ်စေတယ်

အတူတူ စမ်းရေးကြည့်မယ်

function simulateRetries(outcomes, baseDelayMs = 1000) {
  const log = [];
  for (let attempt = 1; attempt <= outcomes.length; attempt++) {
    const outcome = outcomes[attempt - 1];
    const delay = attempt === 1 ? 0 : baseDelayMs * Math.pow(2, attempt - 2);
    log.push({ attempt, waitedMs: delay, outcome });
    if (outcome === "success") break;
  }
  return log;
}

const outcomes = ["fail", "fail", "fail", "success"];
console.log(simulateRetries(outcomes));

attempt 1: outcome=fail, waited=0ms
attempt 2: outcome=fail, waited=1000ms
attempt 3: outcome=fail, waited=2000ms
attempt 4: outcome=success, waited=4000ms
(Delay တစ်ခုစီက အရင် attempt ရဲ့ delay ထက် နှစ်ဆ ဖြစ်နေတာကို သတိပြုပါ — 1000 -> 2000 -> 4000)

Retry-After header - MDN — API Integration & Webhooks