😀 عند شحن المستخدمين وإيداع الأموال، فإن أخطر ما في الأمر ليس عدم وجود ملاحظة، بل التعامل مع الملاحظة باعتبارها بطاقة هوية.
في دليل مسح شحن Moonlight الخاص بالرقم @Dusk ، ركّزت على جملتين متقاربتين تقريبًا.
يعيد المستند memo بصيغة عشرية سداسية (hex) ويصنّفه ضمن بيانات “غير موثوقة” تحتاج إلى التحقق من الصيغة أولًا.
والتنبيه التالي أكثر مباشرة: لا تجعل memo أبدًا مفتاحًا عِديم التكرار (idempotency key). الشيء الوحيد الذي يجب أن يكون هوية وحيدة هو Dusk transaction ID.
هذا الفرق هو الذي يحدد ما الذي تعتبره أنظمة الإيداع حقيقة. memo مجرد إشارة تخبر النظام “ربما ينبغي تسليم هذه لمن”. أما transaction ID فيجيب “هل تمت معالجة هذه الأموال أم لا”. إذا خلطت المنصة بين الاثنين، فسيُساء فهم وسم الواجهة الأمامية الملائم كدفتر حسابات خلفي.
السيناريو السيّئ هو عمليتان شحن تحملان نفس memo أو memo مفقود أو بصيغة غير سليمة. إذا نفّذ النظام إزالة التكرار بناءً على الملاحظة، فقد يتسبب ذلك في نسيان تسجيل عملية واحدة؛ وإذا اعتمد عليها مباشرةً في الإسناد، فقد يدفع الطلبات غير الطبيعية نحو حساب خاطئ. المستخدم لن يرى أن الإيداع لم يأتِ لوقت طويل فحسب، بل سيضطر فريق العمليات إلى مطابقة الأموال والسجلات والطلبات مع العملاء مرارًا.
هذه ليست مشكلة في تصميم memo لرقم $DUSK ، بل في سؤالٍ أبسط: هل على الجهة المُدمِجة أن تعترف بأن معلومات التوجيه بطبيعتها تحتاج إلى تحقق. وقد قدّم دليل @Dusk التوجيه التالي: يجب أن تدخل البيانات الوصفية غير المعروفة أو غير الصالحة إلى مراجعة بشرية، وليس أن تُهمَل بصمت. الجدير بالتحقق حقًا هو ما إذا كانت الجهة المتصلة ستجعل هذه القاعدة جزءًا من المنتج، وتعرض للمستخدم أن حالته تتم معالجتها عبر مراجعة بشرية.#dusk
في دليل مسح شحن Moonlight الخاص بالرقم @Dusk ، ركّزت على جملتين متقاربتين تقريبًا.
يعيد المستند memo بصيغة عشرية سداسية (hex) ويصنّفه ضمن بيانات “غير موثوقة” تحتاج إلى التحقق من الصيغة أولًا.
والتنبيه التالي أكثر مباشرة: لا تجعل memo أبدًا مفتاحًا عِديم التكرار (idempotency key). الشيء الوحيد الذي يجب أن يكون هوية وحيدة هو Dusk transaction ID.
هذا الفرق هو الذي يحدد ما الذي تعتبره أنظمة الإيداع حقيقة. memo مجرد إشارة تخبر النظام “ربما ينبغي تسليم هذه لمن”. أما transaction ID فيجيب “هل تمت معالجة هذه الأموال أم لا”. إذا خلطت المنصة بين الاثنين، فسيُساء فهم وسم الواجهة الأمامية الملائم كدفتر حسابات خلفي.
السيناريو السيّئ هو عمليتان شحن تحملان نفس memo أو memo مفقود أو بصيغة غير سليمة. إذا نفّذ النظام إزالة التكرار بناءً على الملاحظة، فقد يتسبب ذلك في نسيان تسجيل عملية واحدة؛ وإذا اعتمد عليها مباشرةً في الإسناد، فقد يدفع الطلبات غير الطبيعية نحو حساب خاطئ. المستخدم لن يرى أن الإيداع لم يأتِ لوقت طويل فحسب، بل سيضطر فريق العمليات إلى مطابقة الأموال والسجلات والطلبات مع العملاء مرارًا.
هذه ليست مشكلة في تصميم memo لرقم $DUSK ، بل في سؤالٍ أبسط: هل على الجهة المُدمِجة أن تعترف بأن معلومات التوجيه بطبيعتها تحتاج إلى تحقق. وقد قدّم دليل @Dusk التوجيه التالي: يجب أن تدخل البيانات الوصفية غير المعروفة أو غير الصالحة إلى مراجعة بشرية، وليس أن تُهمَل بصمت. الجدير بالتحقق حقًا هو ما إذا كانت الجهة المتصلة ستجعل هذه القاعدة جزءًا من المنتج، وتعرض للمستخدم أن حالته تتم معالجتها عبر مراجعة بشرية.#dusk
