#dusk $DUSK @Dusk

اضطررت لقراءته مرتين لأن HTTP 202 Accepted عادةً ما يريح عقلي.

لكن على Dusk، ربما لا ينبغي.

عندما تُرجع /transactions/propagate 202 Accepted، تكون العقدة قد قبلت المعاملة لأغراض التوجيه.

وحده هذا لا يثبت المعاملة:

دخلت mempool الحقيقي،
وصلت إلى الأقران،
نُفذت بنجاح،
أو تمّت نهائيًا.

في البداية شعرت أن هذا تمييز تقني مُبالغ فيه.

ثم وجدت حالة طرفية أكثر غرابة.

يمكن لمعاملة صالحة لديها nonce مستقبل أن تنتظر في prequeue إلى أن يتم حل فجوة nonce الناقصة.

لذا يمكنك استلام استجابة API نظيفة تمامًا بينما المعاملة ما تزال ليست في المرحلة التي ربما تهتم بها.

كان هذا الجزء مزعجًا بالنسبة لي.

يُبنى الكثير من البنية التحتية حول اختصار بشري جدًا:

قالت API نعم → تم كل شيء.

إرشادات تكامل تبادل Dusk تفترض العكس.

لا ينبغي اعتبار السحب مكتملًا فقط لأن نقطة النهاية الخاصة بالانتشار رجعت 202 Accepted. ما زال يلزم التحقق من التنفيذ والنهائية.

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

هنا يتوقف الأمر عن كونه مجرد فضول متعلق برمز حالة HTTP.

إذا ارتبكت بورصة أو محفظة بين قبول النقل واكتمال الدفتر (ledger)، فقد يتحول اختصار تكاملي صغير إلى مشكلة محاسبية.

ربما أنا أبالغ في التفكير في استجابة API مملة في الليل.

لكنني أعتقد أن التمييز المفيد بسيط:

نجاح النقل ليس نجاح الدفتر.

قد تقول الـ API نعم قبل أن تفعل السلسلة ذلك.