حالات Pending وFailed وDropped: فحص المعاملة قبل إعادة الإرسال

الحالة وصف لبيانات ضمن مصدر ووقت

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

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

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

Pending: معروفة ولكنها لم تُدرج بعد

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

اجمع المرسل والشبكة والمعرف وNonce إن كان ينطبق، ثم افحص هل توجد معاملات أقدم أو بدائل بالرقم نفسه. وقد تميز بعض الأدوات بين قابلية تنفيذ حالي وطابور مستقبلي وفق ما تعرفه. تشرح وثائق Geth لمخزن المعاملات مثالًا على تصنيفات pending وqueued، وهي بيانات عقدة لا وصف سحري يضمن اتفاق كل مصدر في كل لحظة.

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

Failed: افحص هل يوجد تنفيذ مدرج

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

توضح مواصفة EIP-658 معنى حالة النجاح أو الفشل في الإيصال المعني. بالنسبة للمتابعة، افصل سؤال الإدراج من سؤال نجاح الغرض. قد تكون العملية مسجلة وفاشلة التنفيذ، وقد يختلف تعامل المحاولة التالية مع التسلسل والرسوم عن معاملة لم تصل أصلًا إلى كتلة.

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

Dropped: الاختفاء من مجموعة متابعة ليس إلغاءً عامًا

قد يصف مصدر معاملة كانت معروفة له ثم لم يعد يحتفظ بها أو يتابعها ضمن ما يراه من المعاملات غير المؤكدة. تشرح صفحة Etherscan عن المعاملات المسقطة والمستبدلة أن معاملة مسقطة قد تظهر معلقة مجددًا إذا أُعيد بثها بصورة مناسبة. لذلك لا تعامل الكلمة وحدها بوصفها وعدًا بأن الأصل لن ينفذ لاحقًا.

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

أما عبارة Dropped & Replaced فتحتاج إلى متابعة البديل الذي يشير إليه المصدر والتحقق من إدراجه ونتيجته وعلاقته بالأصل. لا تكتف بوجود رابط يحمل كلمة replacement ثم تفترض أن المستلم حصل على المبلغ نفسه؛ قد يكون البديل لتسريع الدفع أو لمحاولة تغيير أثره. اقرأ السجل الذي تأكد فعلًا قبل تسوية الحساب بين الطرفين.

مقارنة تقود إلى فحص مناسب

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

مثال على أصل وبديل وطلب تالٍ

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

وإذا فشلت باء بعد الإدراج، فلا يعني ذلك بالضرورة أن الموضع 9 ما زال ينتظر بالطريقة نفسها. راجع الحالة الحالية للحساب والإيصال وفق نموذجه. أما إذا لم تُدرج أي نسخة، فوجود طلب تالٍ مرتفع الرسوم لا يثبت حل أقدم موضع. هذا المثال للتفسير، وليس تعليمات لإدخال أرقام يدويًا دون قراءة برنامجك وتوثيقه.

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

الرسوم تُراجع من المعاملات التي حدثت فعلًا

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

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

ماذا توثق للدعم وما الذي تبقيه خاصًا؟

جهز الشبكة والمرسل والمعرفات والتسلسل المناسب والحالات وأوقات الفحص ورسالة الخطأ، مع وصف ما حاولت فعله. استخدم القنوات الرسمية للبرنامج أو الخدمة المتحكمة بالمرحلة، ولا تمنح موقع متابعة عبارة الاستعادة أو المفتاح الخاص. قراءة سجل عام لا تحتاج إلى سلطة إنفاق بقية محفظتك أو توقيع صلاحية واسعة لا تفهمها.

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

قائمة مراجعة قبل إجراء جديد

1. طابق الشبكة والمعرف والحساب ونوع المرجع، ثم سجل المصدر والوقت الذي عرض الحالة.
2. افحص وجود إدراج وإيصال وحالة تنفيذ، وميز ذلك عن محاكاة أو رفض قبل الإدراج.
3. راجع التسلسل والبدائل والعلاقات بين المعاملات، خصوصًا عند وصف Dropped أو اختلاف الأدوات.
4. حدد أثر التسريع أو الإلغاء أو المحاولة الجديدة، وراجع الوجهة والقيمة والبيانات والرسوم قبل التوقيع.
5. تابع النتيجة الفعلية واحفظ السجل، دون دفعات مكررة أو حذف أدلة أو مشاركة أسرار بحجة إصلاح الحالة.

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