Promise.allSettled في JavaScript: ليه طلب واحد بيفشل بيقع dashboard كامل

// الكود الغلط — الشائع جداً
async function loadDashboardWrong() {
  const [users, orders, revenue, alerts] = await Promise.all([
    fetch('/api/users').then(r => r.json()),
    fetch('/api/orders').then(r => r.json()),
    fetch('/api/revenue').then(r => r.json()), // افترض ده بيفشل
    fetch('/api/alerts').then(r => r.json())
  ]);

  return { users, orders, revenue, alerts };
}

try {
  const data = await loadDashboardWrong();
  renderDashboard(data);
} catch (err) {
  // هنا الكود مش هيعرف أي طلب نجح
  // الـ users و orders و alerts ضاعوا
  showEmptyDashboard();
}

لو /api/revenue رجع 500 لأي سبب، الـ dashboard كله هيختفي. حتى الطلبات اللي رجعت data صحيحة في 80ms، الكود هياخد decision إنه يخفيها.

الحل بـ Promise.allSettled

كل widget في الـ frontend بقى يقدر يعرض نفسه أو يعرض رسالة "البيانات مش متاحة حالياً" بدل ما الـ dashboard كله يختفي. ده مش بس تجربة مستخدم أحسن، ده برضه بيدي صورة أوضح للـ DevOps عن الـ endpoint اللي بيتعطل.

أرقام من production فعلية

قياس على dashboard بـ 8 endpoints لمدة أسبوع، مع endpoint واحد بيرجع 503 بنسبة ~5% بسبب rate limiting في external API:

• Promise.all: 4.7% من جلسات المستخدمين شافت شاشة فاضية. متوسط زمن الفشل: 180ms (الـ aggregator بيعمل reject بسرعة).
• Promise.allSettled: 0.0% شاشات فاضية. 4.7% من الجلسات شافت widget واحد بـ "البيانات مؤقتاً غير متاحة". متوسط الزمن الكلي: 340ms (لازم ينتظر لحد ما الفاشل يعمل timeout).

الـ trade-off: 160ms زيادة في الزمن مقابل تجربة مستخدم سليمة في 4.7% من الحالات. على dashboard ببزور 800K مستخدم في الشهر، ده 37,600 جلسة كانت هتختفي عليها الواجهة.

متى لا تستخدم Promise.allSettled

Promise.all مش غلط دايماً. استخدمها لما الفشل لازم يوقف العملية كلها:

1. Atomic operations: 3 طلبات بتشكل عملية واحدة منطقياً (transaction). فشل واحد لازم يلغي الباقي.
2. Hard dependencies: الـ data من الطلبات الأربعة كلها مطلوبة لحساب نتيجة واحدة. فشل واحد معناه الحساب مش ممكن، فما فيش لازمة لاستكمال الباقي.
3. Validation gates: بتتحقق من 5 شروط قبل ما تكمل (مثلاً قبل deploy). فشل شرط واحد معناه قف فوراً.
4. Cost-sensitive APIs: لو كل طلب بيكلفك فلوس (مثلاً LLM API)، الـ fail-fast بيحميك من إكمال طلبات قيمتها صفر.

trade-offs لازم تعرفها

• الذاكرة: Promise.allSettled بيحتفظ بـ array كامل من النتايج في الذاكرة. لو بتعمل 10K طلب موازي، ده 10K object في الـ heap. الحل: قسّمهم batches بـ p-limit أو ما شابه.
• Error handling أطول: مع Promise.all فيه catch واحد. مع allSettled لازم تعمل loop وتفحص status لكل نتيجة. الكود أوضح لكن أطول.
• الإلغاء الفعلي: الاتنين مش بيلغوا الطلبات اللي شغالة. Promise.all بيعمل reject بس، لكن fetch requests الباقية بتكمل في الـ background. لو عايز إلغاء فعلي، استخدم AbortController مع الاتنين.
• الـ timeout: allSettled بينتظر الأبطأ. لو فيه endpoint بياخد 30 ثانية، الـ dashboard كله هيستنى 30 ثانية. الحل: لف كل promise في Promise.race مع timeout.

نمط هجين عملي

في تطبيقات production فعلية، النمط الأذكى هو الجمع بين الاتنين: استخدم Promise.all داخل المجموعات اللي ليها dependency حقيقي، و Promise.allSettled على المستوى الأعلى:

الافتراض هنا: عندك مجموعات منطقية من الطلبات. داخل المجموعة fail-fast منطقي، بين المجموعات allSettled منطقي.

الخطوة التالية

افتح ملف الـ dashboard أو الصفحة الرئيسية في تطبيقك دلوقتي. ابحث عن Promise.all. لكل واحدة، اسأل سؤال واحد فقط: "لو الطلب رقم 3 فشل، هل يعقل إن الطلبات 1 و 2 و 4 تتجاهل نتايجها؟". لو الإجابة لا، استبدلها بـ Promise.allSettled وعدّل الـ frontend ليتعامل مع null per widget. خلال أسبوع، شوف عدد المرات اللي شفت فيها شاشة فاضية في تقارير الـ Sentry — هيقل بشكل ملحوظ.

مصادر

• MDN Web Docs — Promise.allSettled: developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Promise/allSettled
• TC39 Proposal — Promise.allSettled (Stage 4, 2019): github.com/tc39/proposal-promise-allSettled
• V8 Blog — Promise combinators: v8.dev/features/promise-combinators
• ECMAScript 2020 Specification (ECMA-262, 11th Edition)
• Node.js Documentation — Promise APIs (Node 18+ تدعم allSettled أصلاً)