HTTP 429 کی خرابی: Retry-After اور محفوظ دوبارہ کوشش کی حکمت عملی

پہلے معلوم کریں کہ 429 کس حصے نے لوٹایا

درخواست کا وقت، راستہ، طریقہ، اسٹیٹس، درخواست کی شناخت اور دوبارہ کوشش سے متعلق ہیڈر محفوظ کریں۔ تصدیقی معلومات اور ذاتی ڈیٹا لاگ میں شامل نہ کریں۔ جواب مطلوبہ API، ریورس پراکسی یا CDN کے اصول سے آیا ہے، یہ جانچیں؛ صرف برانڈ والا خرابی صفحہ حد کی نوعیت نہیں بتاتا۔

MDN کے مطابق حد IP، صارف، ایپ یا کسی وسیلے پر ہو سکتی ہے۔ جواب یا انتظامی صفحہ متعلقہ کوٹا بتا سکتا ہے۔ فی منٹ تعداد، بیک وقت درخواستیں اور روزانہ مجموعی حد الگ مسائل ہیں۔ روزانہ کوٹا ختم ہو تو صرف قطار سست کرنے سے وہ واپس نہیں آتا۔

• کیا کام بڑھا ہے یا کوئی کام مسلسل دوبارہ کوشش کر رہا ہے؟
• کیا مختلف خدمات، ٹیب یا API کیز ایک اکاؤنٹ کا کوٹا بانٹتی ہیں؟
• حد درخواستوں، جاری درخواستوں، ٹوکن یا کسی دوسرے وسیلے پر ہے؟
• کیا بحالی کا بتایا ہوا وقت صارف کے کام کی آخری مدت میں آتا ہے؟

Retry-After کی اکائی درست سمجھیں

Retry-After غیر منفی صحیح عدد، یعنی سیکنڈ، یا HTTP تاریخ ہو سکتا ہے۔ قدر 12 ہو تو جواب ملنے کے بعد بارہ سیکنڈ انتظار ہے، بارہ ملی سیکنڈ نہیں۔ تاریخ ہو تو معتبر گھڑی سے باقی وقفہ نکالیں۔ گزر چکی تاریخ غیر محدود فوری کوششوں کی اجازت نہیں بنتی۔

جو قطار انتظار کر سکتی ہو، اس کے لیے درست سروری وقفہ کم از کم انتظار رکھیں۔ بہت سے ورکر دوبارہ شروع ہوں تو معمولی اتفاقی تاخیر شامل کریں۔ مطلوبہ انتظار باقی مدت سے زیادہ ہو تو کام روکیں یا بعد کے لیے مقرر کریں؛ مقامی زیادہ سے زیادہ حد لگا کر سرور کے وقفے کو کم نہ کریں۔

ہر ورکر کے بجائے پوری مشترک قطار کا بجٹ بنائیں

فرض کریں پورے اکاؤنٹ کو فی منٹ 120 درخواستوں کی اجازت ہے اور کام میں 600 درکار ہیں۔ دوسری سرگرمی نہ ہو تو تعداد کے لحاظ سے بھی کم از کم پانچ منٹ کا کوٹا چاہیے۔ سب درخواستیں دس سیکنڈ میں بھیج کر پچاس سیکنڈ رکنا پھر بھی اچانک بوجھ ہے؛ منٹ کی اوسط درست ہونے کے باوجود انکار ہو سکتا ہے۔

دوسرے کام کے لیے گنجائش رکھنے کو ہدف فی منٹ 90 رکھیں۔ یہ فی سیکنڈ 1.5، یعنی آغاز کے درمیان تقریباً 667 ملی سیکنڈ ہے۔ 600 درخواستوں کو تقریباً 400 سیکنڈ لگیں گے، جواب اور دوبارہ کوشش کا وقت الگ ہے۔ یہ منصوبہ بندی ہے، ہر فراہم کنندہ کی زمانی کھڑکی کی ضمانت نہیں۔

اوسط جواب 2 سیکنڈ ہو تو مستحکم بوجھ میں لٹل کے قانون سے اوسط جاری درخواستیں 1.5 × 2 = 3 بنتی ہیں۔ سیمفور بیک وقت کام، جبکہ مشترک شرح محدود کرنے والا آغاز کا وقفہ سنبھالتا ہے۔ ایک دوسرے کی جگہ نہیں لیتا۔ دوبارہ کوشش بھی اسی بجٹ میں شمار کریں۔

Example workload assumptions:
Account allowance: 120 requests/minute
Operating target: 90 requests/minute = 1.5 requests/second
600 requests / 1.5 requests/second = 400 seconds
Average concurrency at 2 seconds/response: 1.5 × 2 = 3

وقفہ نہ ملے تو محدود بیک آف اور جِٹر لگائیں

مسلسل ناکامی پر انتظار کی حد بڑھائیں اور اس کے اندر اصل وقفہ اتفاقی منتخب کریں۔ مثلاً ایک، دو، چار اور آٹھ سیکنڈ کی کھڑکیاں ہوں، ساتھ الگ مجموعی مدت بھی ہو۔ جِٹر ورکرز کو مختلف وقت پر شروع کرتا ہے تاکہ سب دوبارہ ایک ساتھ خدمت پر نہ پہنچیں۔

نیچے کا فنکشن صرف تاخیر نکالتا ہے، درخواست نہیں بھیجتا اور مکمل کلائنٹ نہیں ہے۔ بلانے والا حصہ مدت، کوششوں کی حد، منسوخی اور عمل دہرانے کی حفاظت سنبھالے گا۔ براؤزر میں Retry-After پڑھنے کے لیے سرور کو CORS کے ذریعے یہ ہیڈر ظاہر کرنا بھی پڑ سکتا ہے۔

function retryDelayMs(retryAfter, attempt, nowMs = Date.now()) {
  const text = String(retryAfter ?? "").trim();
  if (/^\d+$/.test(text)) {
    const milliseconds = Number(text) * 1000;
    return Number.isSafeInteger(milliseconds) ? milliseconds : Infinity;
  }
  if (/^(Mon|Tue|Wed|Thu|Fri|Sat|Sun), \d{2} (Jan|Feb|Mar|Apr|May|Jun|Jul|Aug|Sep|Oct|Nov|Dec) \d{4} \d{2}:\d{2}:\d{2} GMT$/.test(text)) {
    const dateMs = Date.parse(text);
    if (Number.isFinite(dateMs)) return Math.max(0, dateMs - nowMs);
  }
  const windowMs = Math.min(8000, 1000 * 2 ** attempt);
  return Math.floor(Math.random() * windowMs);
}
// Example policy: at most 4 retries and a 30-second total deadline.
// If the required wait exceeds the remaining deadline, stop.

صرف محفوظ طور پر دہرائے جانے والے عمل دوبارہ کریں

وسیلہ پڑھنا اور ادائیگی بنانا مختلف عمل ہیں۔ تحریری کارروائی دہرانے سے پہلے خدمت کا یکساں نتیجے والا معاہدہ اور پچھلی کوشش کے نافذ ہو جانے کا امکان دیکھیں۔ سہولت موجود ہو تو اسی منطقی عمل کی وہی idempotency key رکھیں؛ ہر کوشش پر نئی کی دینے سے الگ کارروائیاں بن سکتی ہیں۔

SDK خود بھی دوبارہ کوشش کر سکتا ہے۔ باہر مزید لوپ لگانے سے اصل نیٹ ورک کوششیں کئی گنا ہو سکتی ہیں۔ سب تہوں کا مجموعی زیادہ سے زیادہ شمار لکھیں۔ صارف کو دیر ہونے پر واضح حالت اور بعد میں کوشش کا راستہ دیں، ہمیشہ گھومتے بٹن کے پیچھے لمبی قطار نہ چھپائیں۔

• پورے کام کی ایک آخری مدت رکھیں اور منسوخی قطار تک پہنچائیں۔
• مشترک کوٹے میں بیک وقت تعداد اور آغاز کی شرح دونوں محدود کریں۔
• انتظار سے پہلے مکمل جواب کے وسائل آزاد کریں۔
• کوٹا ختم ہو یا مستقل ناکامی بتائی گئی ہو تو رکیں۔
• کوششیں اور حتمی نتیجہ ریکارڈ کریں تاکہ نگرانی میں لاگت نظر آئے۔

چھوٹی اور قابو میں رکھی جانچ سے تصدیق کریں

گنی جا سکنے والی چھوٹی پڑھنے کی کھیپ چلائیں۔ ابتدائی کوشش، دوبارہ کوشش، کامیابی اور حتمی ناکامی لکھیں۔ اصل وقفہ اور جاری تعداد منصوبے کے مطابق ہونے چاہییں۔ پھر معلوم Retry-After والا فرضی 429 آزمائیں؛ غلطی سنبھالنے کی جانچ کے لیے حقیقی خدمت پر بار بار دباؤ نہ ڈالیں۔

درخواست شرح کے کیلکولیٹر سے سیکنڈ اور منٹ کی اکائیاں بدلیں، اور بیک وقت درخواستوں والے کیلکولیٹر سے تاخیر کا مفروضہ جانچیں۔ اصل خدمت کی حد سے موازنہ کریں۔ 429 باقی رہے تو اندھا دھند وقفہ بڑھانے سے پہلے مشترک کال کرنے والوں اور کوٹے کی قسم دیکھیں۔