التراجع عند الخطأ وحل التعارضات

تُعد إعادة عملية إضافة متفائلة إلى الحالة السابقة، وذلك بإزالة العنصر، أو إعادة عملية حذف، وذلك باستعادة العنصر، أمرًا مباشرًا. أما إعادة عملية تحديث فتكون أكثر تعقيدًا، إذ يجب استعادة القيمة السابقة بدقة. إذا حُدّث العنصر عدة مرات بتفاؤل، فيجب تتبّع كل قيمة سابقة على حدة، وليس حالة الخادم الأصلية فقط.

تأمّل هذا السيناريو: يحتوي الخادم على عنصر قيمته Z. تُحدّثه بتفاؤل إلى X. وأثناء وجود طلبك قيد التنفيذ، يحدّث مستخدم آخر العنصر نفسه إلى Y على الخادم. يصل طلبك ويرفضه الخادم بسبب التعارض. هدف التراجع لديك هو Z، لكن الحالة الحالية على الخادم هي Y. ستؤدي استعادة Z إلى الكتابة فوق Y بشكل غير صحيح.

تتمثل استراتيجية التراجع الأكثر أمانًا عند تحديث العناصر في إعادة جلب العنصر من الخادم عند حدوث أي خطأ في عملية التغيير، بدلًا من استعادة نسخة محفوظة محليًا. يضمن ذلك عرض حالة الخادم المعتمدة، بغض النظر عما قد يكون المستخدمون الآخرون قد غيّروه بالتزامن. إعادة الجلب أبطأ، لكنها صحيحة دائمًا.

تعيد واجهة برمجة التطبيقات المصممة جيدًا HTTP 409 Conflict عندما يفشل تحديث متفائل بسبب تعديل متزامن. يتضمن نص الاستجابة عادةً الحالة الحالية على الخادم. ينبغي لمعالج الأخطاء اكتشاف الحالة 409، واستخدام نص الاستجابة لتحديث حالتك المحلية بالقيمة الحالية على الخادم، وإبلاغ المستخدم بأن تغييراته لم تُحفَظ.

تنتج عملية التغيير idempotent النتيجة نفسها عند تطبيقها عدة مرات. ويجعل تصميم عمليات التغيير لتكون idempotent، باستخدام PUT بدلًا من POST، وتضمين الحالة الكاملة للمورد، واستخدام مفاتيح idempotency، إعادة المحاولة عند الفشل آمنةً دون خطر تطبيق التغيير مرتين. وهذا يبسط منطق التراجع بدرجة كبيرة.

قد تؤدي النقرات المزدوجة على زر الإرسال إلى تشغيل عمليتي تغيير متطابقتين. امنع ذلك باستخدام علامة isSubmitting: اضبطها على true عند بدء عملية التغيير، وأعد ضبطها عند اكتمالها، سواء نجحت العملية أم فشلت. عطّل عنصر التشغيل عندما تكون isSubmitting تساوي true. يؤدي ذلك إلى إزالة عمليات التغيير المكررة على مستوى واجهة المستخدم.

لإزالة التكرار على جانب الخادم، أدرج رأس Idempotency-Key فريدًا مع كل طلب تغيير. أنشئه باستخدام crypto.randomUUID() عندما يبدأ المستخدم الإجراء. يكتشف الخادم المفاتيح المكررة ويعيد الاستجابة نفسها التي أعادها الطلب الأصلي، من دون إعادة تطبيق العملية.

أثناء وجود عملية التغيير قيد التنفيذ، يمكنك عرض مؤشر بسيط يوضح أن الحالة المتفائلة لم تُؤكَّد بعد، مثل نقطة صغيرة نابضة، أو نص "جارٍ الحفظ..."، أو تقليل مستوى عتامة العنصر. يوضّح ذلك حالة عدم اليقين دون منع التفاعل. أزل المؤشر عند النجاح، أو أعد الحالة السابقة عند الفشل.

قد تؤدي الأخطاء غير المتوقعة في منطق التراجع، مثل الوصول إلى خصائص قيمة غير معرّفة أثناء استعادة الحالة، إلى تعطيل المكوّن. ضع المكوّنات التي تعتمد بكثرة على عمليات التغيير داخل حدّ أخطاء، بحيث تعرض حالات فشل التراجع الكارثية واجهة خطأ مناسبة بدلًا من شاشة فارغة. سجّل هذه الأخطاء لأغراض التصحيح.

تتمثل استراتيجية موثوقة لاكتشاف التعارضات في تضمين رقم إصدار أو ETag مع كل عملية تغيير. يقارن الخادم الإصدار الذي أرسله العميل بإصداره الحالي. وإذا اختلفا، أي حدث تحديث آخر، يعيد الخادم الحالة 409. يُسمى هذا التحكم في التزامن المتفائل؛ إذ تفترض عدم وجود تعارض، لكنك تكتشفه عند حدوثه.

غالبًا ما لا يُختبر منطق التراجع لأن محاكاة أعطال الشبكة صعبة. استخدم أدوات مثل Mock Service Worker (MSW) لإعادة استجابات خطأ في الاختبارات. اكتب اختبارات صريحة للتعامل مع 409 Conflict، والتراجع بعد انتهاء مهلة الشبكة، وإزالة التكرار عند النقر المزدوج، واتساق الحالة بعد الفشل. تختبئ الأخطاء غالبًا في هذه الحالات الطرفية.

ما رمز حالة HTTP الذي تعيده واجهة برمجة التطبيقات المصممة جيدًا عندما يفشل تحديث متفائل بسبب تعديل متزامن أجراه مستخدم آخر؟

تراجع التحديث أكثر تعقيدًا من الإضافة أو الحذف، لذا أعد الجلب دائمًا عند الخطأ لتجنب مشكلات النسخ المحفوظة القديمة. تشير حالة HTTP 409 Conflict إلى فشل التزامن المتفائل؛ استخدم نص الاستجابة لاستعادة الحالة الحالية على الخادم. صمّم عمليات التغيير لتكون idempotent من أجل إعادة المحاولات بأمان. امنع التشغيل المزدوج باستخدام isSubmitting ومفاتيح idempotency على الخادم. اختبر مسارات التراجع صراحةً باستخدام MSW لمحاكاة الأخطاء.