انتقل إلى المحتوى
العودة إلى وثائق Launch

تنزيل Markdownالوثيقة الأصلية على GitHub

إصلاح تزامن تعيين منتجات خطط Launch

أُصلحت AUTH-03 في مراجعة الترخيص. عُدّل خادم Launch واختبارات الانحدار المقابلة فقط، دون نشر أو إصدار SDK؛ ولم تتغير حدود قرارات الترخيص في Licentivo وSDK.

التغييرات

  • عند حفظ التعيين يُقفل أولًا سجل منتج Launch المشترك داخل المعاملة، ثم إصدار الخطة. تتبع طلبات الحفظ من خطط أو عمليات مختلفة قفل المنتج نفسه؛ ويعيد الطلب المتعارض HTTP 409 PRODUCT_MAPPING_CONFLICT.
  • يحفظ products.licentivo_product_id مسار المنتج العام الثابت. بعد أول حفظ ناجح للتعيين لا تستطيع الخطط الأخرى لمنتج Launch نفسه اختيار سوى منتج Licentivo هذا، مع السماح باختيار سياساته المختلفة. لا يحفظ الحقل أذونات الميزات أو حصة الأجهزة أو حالة ترخيص العميل.
  • تقرأ هوية العميل المسار الثابت بدلًا من اختيار المنتج وفق أكبر إصدار لجميع الخطط. يُفحص الربط نفسه عند نشر الخطة وإنشاء إعداد تكامل SDK.
  • تضيف قاعدة البيانات القديمة تلقائيًا حقلًا يقبل null. تُراجع البيانات التي لا تملك الحقل الثابت بالتتابع وفق تاريخ الشراء مثل المدفوعات، وسجلات النشر السابقة، ثم التعيينات الأخرى؛ وعند وجود منتجات متعددة في الأولوية نفسها يُبلغ عن التعارض صراحة دون تخمين. يُفضل المنتج المشتَرى الوحيد على المسودات غير ذات الصلة، ويمكن لحفظ تعيين متوافق لاحقًا تثبيت الربط. يحافظ تعديل محتوى المنتج على الربط.

تظل البيانات التاريخية الخاطئة المباعة إلى منتجات Licentivo متعددة بحاجة إلى مراجعة يدوية؛ ولا تعيد هذه العملية كتابة سجلات الشراء أو التراخيص البعيدة. عند الحاجة إلى منتج Licentivo آخر يجب إنشاء منتج Launch جديد، ولا يجوز استخدام خطة جديدة لإعادة كتابة مسار المنتج الأصلي.

راجع التنفيذ في حفظ التعيين ومسار المنتج وإصدار الهوية والتحقق من النشر وفحص التكامل ونموذج البيانات.

التحقق المحلي

الفحص النتيجة
مقارنة التنفيذ قبل الإصلاح رصد اختبار الانحدار نفسه باستمرار نجاح حفظين متعارضين معًا، وفشل كما هو متوقع
انحدار التعيين المتخصص بعد الإصلاح نجح أحد الطلبين المتعارضين وأعاد الآخر 409؛ ونجح الحفظان المتوافقان؛ لم تتأثر الهوية بالمسودة الخاطئة بعد مزامنة الدفع؛ وقبلت طبقة تكامل SDK سياق المنتج الصحيح
حماية البيانات التاريخية نجحت أولوية المسار المشتَرى والإبلاغ عن الغموض ومنع نشر المسودة الخاطئة ومنع إنشاء إعداد SDK من نشر تاريخي خاطئ والحفاظ على الربط عند تعديل المحتوى
جميع حزم مصدر Go وانحدار MySQL 192 سجل اختبار ناجح، بما فيها الحالات الفرعية؛ دون فشل. تم تخطي TestProductUploadRoundTrip ولم يُحسب ناجحًا
ترقية بنية قاعدة البيانات القديمة أُكملت البنية التي تفتقر إلى عمود المسار بحقل يقبل null بعد التهيئة؛ ونجحت التهيئة المتكررة
الاختبار المشترك الحقيقي لـ Launch وLicentivo وGo SDK نجحت 13 مرحلة أعمال تشمل الشراء وتنفيذ ميزة موقعة فعلية والاستعادة بعد الإغلاق العادي والخروج وفك الربط عن بُعد والجيل القديم واسترداد التجديد وإلغاء الحساب ورفض التشغيل بعد الاسترداد/رد المبلغ
الاختبار الإضافي النهائي نجح انحدار التعيين المتخصص في قاعدة فارغة جديدة، بما فيه فحص إعداد تكامل النشر التاريخي؛ ونجح go vet

بعد اكتمال الانحدار الكامل والاختبار المشترك للخدمات الحقيقية أضيف أخيرًا فحص اتساق تكامل SDK، وأعيد تشغيل الانحدار المتخصص الذي يتضمن هذا السيناريو وgo vet بصورة منفصلة. يثبت الفشل المتوقع للتنفيذ القديم قدرة الاختبار على التقاط السباق الأصلي، وليس فشل انحدار غير محلول.

استخدم الاختبار المشترك MySQL 8.0.32 محليًا معزولًا وخدمة Licentivo الحالية وGo SDK فعليًا؛ واستخدمت قنوات الدفع وDeepL خدمات محاكاة معزولة دون خصم فعلي أو ترجمة مدفوعة. استخدمت اختبارات التزامن والتعيين التاريخي الخاطئ أعمال Launch الفعلية وMySQL ومحاكي البروتوكول؛ ولا يُدعى أن حزم SDK التسع أكملت كلها اختبار خدمات حقيقية في هذه الجولة.

لم يُزَر 192.168.2.177 في هذه الجولة. أُوقفت عمليتا MySQL وLicentivo المؤقتتان اللتان بدأتا لهذه المهمة، مع إبقاء الخدمات السابقة. تُحفظ المواد الأصلية في الدليل المتجاهل .local/mapping-fix-20261024/؛ وراجع أدلة التحقق للملخص القابل للمشاركة.