إعادة إرسال إيصالات Loops: ثبّت المحتوى المعتمد

محاولة الإرسال الجديدة (retry) ما لازم تتحول بالسر إلى إيصال مختلف. إذا صار timeout في مهمة Node، وقرأت المحاولة التالية template تم تعديله للتو أو تفاصيل طلب تغيرت، الفريق ما رح يقدر يعرف أي رسالة استلمها العميل فعلياً.

جهّز تصميم الإيصال المعتمد داخل Migma، وخلّي المسؤولين عن Node وLoops يحافظوا على تفاصيل العملية التجارية المعتمدة ويسوّوا أي إرسال غير مؤكد (reconciliation). هذا الدليل منشور من Migma، ويركّز على الاتفاق الإبداعي (creative contract) حول الـ retries، مش على إعداد integration للإرسال ولا يدّعي أن Migma تشغّل Loops تلقائياً.

حدد شو بيعتبر نفس الرسالة

لنفترض وجود طلب افتراضي لدفترين. الإيصال الأساسي بيذكر المنتجات، المجموع المعتمد، ورقم الطلب المرجعي. هذه الحقائق بتوصف حدثاً تجارياً محدداً. أما استرداد المبلغ (refund) لاحقاً أو تعديل العنوان، فهو تغيير لازم يُدرس بوضوح، مش تفصيل يمر بالسر داخل الـ retry بدون مراجعة.

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

السؤال الأساسي مش بس: «هل اشتغل الكود مرة ثانية؟»، بل: «هل كانت المحاولة التالية تهدف لإرسال نفس الحدث المعتمد للشخص نفسه؟». إذا تغيّر الجواب، وقّف التعامل مع الإجراء كـ retry عادي، واسأل المسؤول كيف لازم تتم معالجة التصحيح.

افصل اعتماد التصميم عن هوية الإرسال

يجهّز الـ workflow الموثّق في Migma النصوص والتصميم والصور ونسخة بريد إلكتروني آمنة بهدف المراجعة. هذا بيسهّل الاتفاق على مظهر الإيصال وصياغته، لكنه ما بيحدد أي طلب قبله المزود (provider) أو إذا كان العميل استلمه فعلياً.

احتفظ بالملف الإبداعي المعتمد مع ربط الحدث بالـ template المخصص له. إذا كانت الوجهة تستخدم template مشتركاً في Loops، وثّق كيف بيتحكم الكود بالتغييرات طالما في مهمة إرسال معلقة (pending). لا تفترض أبداً أن حفظ screenshot محلي بيجمّد الـ template المستخدم بالتطبيق.

راجع المحتوى الفعلي والإجراء المطلوب (CTA). رابط حالة الطلب لازم يشير لنفس الطلب الموجود بالإيصال؛ وجود زر عام مثل «عرض طلبك» ما بيعفي من الخطأ إذا كان الرابط بياخد لمكان غير صحيح. اطلب من مسؤول التنفيذ فحص نماذج معبأة ببيانات حقيقية، مش بس متغيرات فارغة.

التزم بالاتفاق الحالي للـ retry من المزود

يشرح دليل Loops الخاص بـ Node كيفية إرسال رسائل المعاملات (transactional emails) والتعامل مع الـ retries. لمعرفة سلوك المزود بدقة، ارجع إلى توثيق الـ transactional endpoint، المحدّث لهذا الدليل بتاريخ 17 تشرين الأول / أكتوبر 2026.

يوضح هذا الـ endpoint إمكانية استخدام Idempotency-Key اختياري لتفادي تكرار الطلبات، واستجابة 409 بحال استُخدم المفتاح مسبقاً ضمن الإطار الزمني المحدد. على مسؤول الإرسال تطبيق هذا العقد بدقة؛ اختيار مفتاح جديد لمجرد تجاوز الـ conflict قد يكسر حماية التكرار اللي الفريق عم يحاول يحافظ عليها.

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

راجع ثلاث حالات قبل الإطلاق

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

عند تعديل الإيصال، حدد شو اللي تغير ولأي سبب. تعديل الكمية أو استرداد المبلغ أو تغيير المستلم قد يتطلب رسالة معتمدة ومستقلة. تجنب استبدال معنى الرسالة الأولى لمجرد جعل أحدث screenshot تبدو صحيحة.

عند الحصول على استجابة غير مؤكدة، تعامل معها كحالة معلقة حتى تتم تسويتها. حدوث timeout لا يعني أن المزود لم يقبل الطلب. لا تخلي رغبة فريق التسويق بـ «التأكد من الوصول» تؤدي لإرسال ثانٍ غير مراجع عبر مسار مختلف.

تحقق من الشكل النهائي للإيصال

اعتمد على تصدير HTML من Migma (HTML handoff) كمرجع إبداعي تمت مراجعته. ويجب على مسؤول Loops تأكيد الطريقة المدعومة لتطبيق التصميم وتعبئة متغيراته. هذا الدليل لا يفترض وجود ربط مباشر (native connection) بين Migma وLoops.

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

شغّل Email Preflight لفحص النصوص والروابط والتخطيط والمعاينة في بريد الوارد. بعدها، استخدم مسار الاختبار المعتمد لدى مسؤول الإرسال لفحص الـ template النهائي وحالات الـ retry. فحص التصميم وحده لا يضمن قبول المزود أو وصول الرسالة للـ inbox.

اجعل التصحيحات واضحة للفريق

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

النتيجة العملية هي إيصال يقدر الفريق يشرحه بوضوح: شو بيقول، أي حدث بيوصف، وأي إثبات إرسال يدعم حالته. ابدأ الجانب الإبداعي في Migma، واحرص على ربط قرارات الـ retry بسجلات المزود والتطبيق الفعلية.

الأسئلة الشائعة