“تمت الإزالة” وضع هذا اللفظ في مراقبة المعاملات قد يُقرأ بسهولة على أنه “فشل”، لكن عندما رأيت حدث RUES للرقم @Dusk أُوقفت قليلًا؛ لأن خروج معاملة من mempool المحلي لا يعني بالضرورة أنها رُفضت على السلسلة. هذه ليست لعبة كلمات؛ فالتوضيح الرسمي من Dusk فيtransactions/removed لا يعني إلا أنها غادرت mempool محليًا لأحد العقد. والسبب قد يكون إدخالها في كتلة، أو استبدالها بمعاملة متعارضة ذات gasPrice أعلى، أو انتهاء صلاحيتها، أو الاستبعاد بسبب السعة، أو ببساطة لأن المعاملة المتعارضة هي التي غادرت. ومن خلال هذا الحدث وحده لا تخبرك المنظومة بالنتيجة النهائية.

هذا جعلني أعيد النظر في تجربة مطوّر $DUSK : عندما تُحوِّل الشاشة removed إلى فشل فإنها تُرسل تنبيهًا مبكرًا جدًا إلى الخلفية، أما إذا اعتبرتها نجاحًا فقد تفوّت المعاملات التي تم استبعادها فعلًا. في الواقع، يقسم حقل حالة بين “ما الذي يحدث أمام العقدة” و“ما الذي تذكره السجلات أخيرًا” إلى طبقتين. في سيناريو الضغط، هذا أمر شائع: بعد أن يحوّل المستخدم، يستقبل المحفظة removed وتُظهر له “يرجى المحاولة مرة أخرى”، ثم يرسل معاملة ثانية وبعد ذلك يكتشف أن المعاملة الأولى كانت قد دخلت في كتلة بالفعل؛ فيدفع غازًا إضافيًا، ويضطر فريق الدعم إلى شرح أي معاملة كانت فعّالة. إن كانت رسالة الخطأ لا تُراجع السجلّ بل تعتمد فقط على الأحداث، فستُضخِّم “العرض المحلي” إلى أنها حقيقة.

لذلك لن أعتبر removed الخاصة بـ RUES إشارة فشل. الوثائق الخاصة بـ @Dusk تعطي اتجاهًا أكثر أمانًا: راجع المعاملة وحالة الكتل ثم قرر ما إذا كان ينبغي إعادة المحاولة. بعد ذلك سأتحقق مما إذا كانت المحفظة تعرض للمستخدم بشكل منفصل “الإزالة من المحلي” و“النتيجة النهائية”—وهذه هي التفاصيل التي تساعد Dusk المستخدمين على تجنّب الوقوع في الأخطاء. #dusk