Cardano-db-sync: حلقة لانهائية من الذعر / التراجع (فشل NewEpoch)

هل هذا مينيت؟ هل تقوم بالترقية من إصدار البرنامج إلى إصدار آخر؟

~ يشير الجزء NewEpochFailure من رسالة الخطأ إلى أن إصدار db-sync غير متوافق مع إصدار node . ~

الإصدار 6.0.x من db-sync متوافق مع 1.21.x من العقدة.

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

إغلاق هذا.

لقد قمت للتو بضرب هذا على خادم CI cardano-graphql ، دون أي تغيير في الاهتمام مثل تحديثات الإصدار. الاتصال بشبكة mainnet مع هذا التكوين .

[db-sync-node:Error:62741] [2020-11-12 06:02:09.50 UTC] runDBThread: Panic! applyHeaderTransition failed: [[NewEpochFailure (EpochFailure (NewPpFailure (UnexpectedDepositPot (Coin 831366000000) (Coin 831368000000))))]]
CallStack (from HasCallStack):
  error, called at src/Shelley/Spec/Ledger/API/Validation.hs:92:15 in shelley-spec-ledger-0.1.0.0-3QeazRqhkmeDSfJ73hDh1U:Shelley.Spec.Ledger.API.Validation
[db-sync-node:Error:62736] [2020-11-12 06:02:09.50 UTC] ChainSyncWithBlocksPtcl: Panic! applyHeaderTransition failed: [[NewEpochFailure (EpochFailure (NewPpFailure (UnexpectedDepositPot (Coin 831366000000) (Coin 831368000000))))]]
CallStack (from HasCallStack):
  error, called at src/Shelley/Spec/Ledger/API/Validation.hs:92:15 in shelley-spec-ledger-0.1.0.0-3QeazRqhkmeDSfJ73hDh1U:Shelley.Spec.Ledger.API.Validation
[db-sync-node.Subscription:Error:62732] [2020-11-12 06:02:09.50 UTC] [String "Application Exception: LocalAddress {getFilePath = \"/node-ipc/node.socket\"} Panic! applyHeaderTransition failed: [[NewEpochFailure (EpochFailure (NewPpFailure (UnexpectedDepositPot (Coin 831366000000) (Coin 831368000000))))]]\nCallStack (from HasCallStack):\n  error, called at src/Shelley/Spec/Ledger/API/Validation.hs:92:15 in shelley-spec-ledger-0.1.0.0-3QeazRqhkmeDSfJ73hDh1U:Shelley.Spec.Ledger.API.Validation",String "SubscriptionTrace"]
[db-sync-node.ErrorPolicy:Error:4] [2020-11-12 06:02:09.50 UTC] [String "ErrorPolicyUnhandledApplicationException Panic! applyHeaderTransition failed: [[NewEpochFailure (EpochFailure (NewPpFailure (UnexpectedDepositPot (Coin 831366000000) (Coin 831368000000))))]]\nCallStack (from HasCallStack):\n  error, called at src/Shelley/Spec/Ledger/API/Validation.hs:92:15 in shelley-spec-ledger-0.1.0.0-3QeazRqhkmeDSfJ73hDh1U:Shelley.Spec.Ledger.API.Validation",String "ErrorPolicyTrace",String "LocalAddress {getFilePath = \"/node-ipc/node.socket\"}"]
[db-sync-node.Handshake:Info:62759] [2020-11-12 06:02:17.54 UTC] [String "Send (ClientAgency TokPropose,MsgProposeVersions (fromList [(NodeToClientV_1,TInt 764824073),(NodeToClientV_2,TInt 764824073),(NodeToClientV_3,TInt 764824073)]))",String "LocalHandshakeTrace",String "ConnectionId {localAddress = LocalAddress {getFilePath = \"\"}, remoteAddress = LocalAddress {getFilePath = \"/ipc/node.socket\"}}"]
[db-sync-node.Handshake:Info:62759] [2020-11-12 06:02:17.54 UTC] [String "Recv (ServerAgency TokConfirm,MsgAcceptVersion NodeToClientV_3 (TInt 764824073))",String "LocalHandshakeTrace",String "ConnectionId {localAddress = LocalAddress {getFilePath = \"\"}, remoteAddress = LocalAddress {getFilePath = \"/ipc/node.socket\"}}"]
[db-sync-node:Info:62763] [2020-11-12 06:02:17.54 UTC] Starting chainSyncClient
[db-sync-node:Info:62763] [2020-11-12 06:02:17.55 UTC] Cardano.Db tip is at slot 13564796, block 4938498
[db-sync-node:Info:62768] [2020-11-12 06:02:17.55 UTC] Running DB thread
[db-sync-node:Info:62768] [2020-11-12 06:02:18.01 UTC] Rolling back to slot 13564796, hash 5d8ea0d4cf2d4f46cc91aa48e83c029691f836d7200e11e26402f9a2bcb25987
[db-sync-node:Info:62768] [2020-11-12 06:02:18.01 UTC] Deleting slots numbered: []
[db-sync-node:Error:62768] [2020-11-12 06:02:19.47 UTC] runDBThread: Panic! applyHeaderTransition failed: [[NewEpochFailure (EpochFailure (NewPpFailure (UnexpectedDepositPot (Coin 831366000000) (Coin 831368000000))))]]
CallStack (from HasCallStack):
  error, called at src/Shelley/Spec/Ledger/API/Validation.hs:92:15 in shelley-spec-ledger-0.1.0.0-3QeazRqhkmeDSfJ73hDh1U:Shelley.Spec.Ledger.API.Validation
[db-sync-node:Error:62763] [2020-11-12 06:02:19.47 UTC] ChainSyncWithBlocksPtcl: Panic! applyHeaderTransition failed: [[NewEpochFailure (EpochFailure (NewPpFailure (UnexpectedDepositPot (Coin 831366000000) (Coin 831368000000))))]]
CallStack (from HasCallStack):
  error, called at src/Shelley/Spec/Ledger/API/Validation.hs:92:15 in shelley-spec-ledger-0.1.0.0-3QeazRqhkmeDSfJ73hDh1U:Shelley.Spec.Ledger.API.Validation
[db-sync-node.Subscription:Error:62759] [2020-11-12 06:02:19.47 UTC] [String "Application Exception: LocalAddress {getFilePath = \"/node-ipc/node.socket\"} Panic! applyHeaderTransition failed: [[NewEpochFailure (EpochFailure (NewPpFailure (UnexpectedDepositPot (Coin 831366000000) (Coin 831368000000))))]]\nCallStack (from HasCallStack):\n  error, called at src/Shelley/Spec/Ledger/API/Validation.hs:92:15 in shelley-spec-ledger-0.1.0.0-3QeazRqhkmeDSfJ73hDh1U:Shelley.Spec.Ledger.API.Validation",String "SubscriptionTrace"]
[db-sync-node.ErrorPolicy:Error:4] [2020-11-12 06:02:19.47 UTC] [String "ErrorPolicyUnhandledApplicationException Panic! applyHeaderTransition failed: [[NewEpochFailure (EpochFailure (NewPpFailure (UnexpectedDepositPot (Coin 831366000000) (Coin 831368000000))))]]\nCallStack (from HasCallStack):\n  error, called at src/Shelley/Spec/Ledger/API/Validation.hs:92:15 in shelley-spec-ledger-0.1.0.0-3QeazRqhkmeDSfJ73hDh1U:Shelley.Spec.Ledger.API.Validation",String "ErrorPolicyTrace",String "LocalAddress {getFilePath = \"/node-ipc/node.socket\"}"]

~ بعد الدردشة مع Rhys على Slack ، أظن أنه في حالته ، واجه db-sync مشاكل تزيد عن 1000 كتلة قبل حدوث هذا الخطأ وما يراه هو نتيجة لإعادة تشغيل السجلات وتدويرها. ~

تحدث المشكلة في فترة التمديد.

تلكrhyslbw واشتعلتmmahut كلا barfed على نفس كتلة التطبيقية الماضي، تجزئة 5d8ea0d4cf2d4f46cc91aa48e83c029691f836d7200e11e26402f9a2bcb25987 . من غير المرجح أن تكون هذه مصادفة.

من المحتمل جدًا أن تكون هذه الكتلة هي اللبنة الأولى لعصر جديد.

rhyslbw ما هو تجزئة git db-sync الذي تستخدمه؟

تم الالتزام باستخدام https://github.com/input-output-hk/cardano-db-sync/commit/6187081a7ea66954c86094578bd37e01bca8aaec الذي ينقصه الالتزام https://github.com/input-output- hk / cardano-db-sync / الالتزام / afe68e08cf5f8b3b1b6690e411670908bc0f5942 الذي يحتوي على تغييرات في تكوين حالة دفتر الأستاذ. تتعلق هذه المشكلة بموتها في الكود المرتبط بحالة دفتر الأستاذ ، ولكن هذا التغيير لا ينبغي أن يحدث فرقًا على الشبكة الرئيسية. العلامة 6.0.0 بعد التنفيذ الثاني.

هذا ألم هائل في الرقبة يجب تصحيحه دون إصلاح لـ https://github.com/input-output-hk/cardano-db-sync/issues/256 .

erikd أنا أستخدم علامة الإصدار الالتزام 3e68f3011bb156b9b799ccf056f9a73281479f9c

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

10 عقد ، تحطمت جميعها بسبب هذا الخطأ المحدد. الدولة هي:

65bce9e6463a324d612d24588afbdecc  13996555.lstate
77b5e894f8a22cb49605b9bfd474588a  13996568.lstate
12c4be3b0fac587d1b6485284e218404  13996582.lstate
f0b29f6768c836e7283f7033799ce146  13996626.lstate
ba72f63cf8185150c8120f3466756479  13996646.lstate
a2b45038665701084196a238b3beb329  13996669.lstate
7e8cccd8f0f1c3ac519ef7471a998ac1  13996713.lstate
ab304c279c8209e4b21a623b1a6dd80f  13996756.lstate

واستخدام git rev 6187081a7ea66954c86094578bd37e01bca8aaec (وهو زوج من الالتزامات خلف علامة 6.0.0 ).

الفرضية الحالية هي أن حالة دفتر الأستاذ تتعرض للتلف في مرحلة ما وأن الفساد لا يُلاحظ إلا عند حدود العصر.

حلقة لانهائية NewEpochFailue

99d3e16a319a20ff689ca9582425ddae  13996555.lstate
8205deb9c2b3ad946a99bc7692d4434e  13996568.lstate
8eeb20d372cf5214db7c8287a052707b  13996582.lstate
7133fb72aa8194efa80e95c3fa4af1fb  13996626.lstate
f7199d4a131c6fd4649a76a51167275f  13996646.lstate
faa8d71771e8cc68703fa4f1f08dfce7  13996669.lstate
f6cbf62dad57439dc126f8b56061a863  13996713.lstate
504ea06cb925868c25c100d7d05d6afd  13996756.lstate

cardano-db-sync-extended 6.0.0 - linux-x86_64 - ghc-8.6
git revision 3e68f3011bb156b9b799ccf056f9a73281479f9c

ألقى 2 من 3 مثيلات الخطأ NewEpochFailue .
مراجعة git 3e68f3011bb156b9b799ccf056f9a73281479f9c

0eb144b880dcb07c8347b560ea77db27  13996555.lstate
6ee65fc1f5d47fbb858e92770e109f0f  13996568.lstate
c526b055c731173bb7a94cbf3144855d  13996582.lstate
932f8a4807537c43332a4b9a91c0c4a7  13996626.lstate
95163e7b5351b04ae5909d221a4ee2e2  13996646.lstate
c584485911b8f246d01e37572b0f4175  13996669.lstate
449a7c5b2669288dfec995867507211a  13996713.lstate
ba8c8f7f1657727c826ca07be4f7d2e2  13996756.lstate

تم طرح لقطات المثيل التي لم تتأثر.

حقيقة أن ملف حالة دفتر الأستاذ نفسه ، على سبيل المثال 13996756.lstate يحتوي على ثلاث تجزئات مختلفة هو أمر غير متوقع بعض الشيء.

إذا كان السبب هو حالة دفتر أستاذ تالف ، فمن المحتمل أن تكون هذه الحالة و # 405 هي نفس المشكلة

SebastienGllmt نعم ، هذا ممكن ، لكن لم تتح لي الفرصة حتى للنظر في # 405 حتى الآن.

2 من أصل 4 حالات تم إلقاؤها
MD5 الاختباري لمثيل فاشل:

189def79f03972649fdcdcd811def1bb  13996555.lstate
dc6865de6149fdf4879a4659bcf02ef0  13996568.lstate
85bf1965fdadee3ee42c10dfd32e0bdb  13996582.lstate
c452477105dc4041c17d718a32f12056  13996626.lstate
9eb0f1fd0a165a8eff3ec4835f370d6d  13996646.lstate
4d5180ba656234020a71f2d46f1d9d0e  13996669.lstate
521ae28570c1630a18bc721cc4707eaa  13996713.lstate
9a2485e192578c1d3c22059648fba79f  13996756.lstate

(يحتوي المثيل الفاشل الآخر على تجزئات مختلفة)

مثال صحي:

98d46070c972d7b4ec564e4053e29eda  14033709.lstate
5c2443fe558a928a86606136337f3648  14033754.lstate
6c180d350ba7becf0f02d698ac160397  14033800.lstate
d655e560b8a43e064b671266795d262c  14033812.lstate
99bfbf88ec497e7e40865c920f8e8e26  14033839.lstate
bec82d94fe348d843389853cd24a3e5b  14033845.lstate
14faba941a24f02b236d784af85f8d32  14033890.lstate
c96d18f7bdadebed8e3b723b4e6691fc  14033936.lstate

حاولت إعادة مزامنة 10 مثيلات مختلفة عند الالتزام bcd82d0a3eada57fdf7cc71670a46c9b3b80464f (حيث أحتاج إلى ميزة البيانات الوصفية).

2 من أصل 10 لديهم نسخة تالفة من ملفات حالة دفتر الأستاذ (تختلف عن البقية). المبالغ الصحيحة هي:

/var/lib/csyncdb/14040345.lstate | b1df6bdb2cf6f798d9baf83373a4698f
/var/lib/csyncdb/14040390.lstate | 5694a00b12b47052125178175289ba24
/var/lib/csyncdb/14040394.lstate | b45a5e4b82362def92225a3eec5d1afb
/var/lib/csyncdb/14040412.lstate | 8319589d1b66dffd97f5233c3dcfddd0
/var/lib/csyncdb/14040436.lstate | 9d0fec3f4693bd78f426c34c5aaa5d5d
/var/lib/csyncdb/14040462.lstate | 8afe16d592a57ed5ef79a27adf0803d9
/var/lib/csyncdb/14040481.lstate | bcc2648eb09b0d5503f6397569b33e67
/var/lib/csyncdb/14040527.lstate | 588d787363bfe02cf0fd34ac8f412dd4
/var/lib/csyncdb/14040553.lstate | e1f2f42a1ac49d2ec3a53351d1b267b5

لقد لاحظت أيضًا عدم تناسق في الملفات. 14040345.lstate مفقودًا في نصف الحالات ، ولكن هذه المثيلات بها 14040553.lstate بدلاً من ذلك.

لمعلوماتك ، نفس المشكلة مرة أخرى في عصر الانتقال 230 ...

حسنًا ، أعرف سبب المشكلة. إصلاح هذا بسيط نسبيًا. لن يتطلب الإصلاح إعادة مزامنة db ما لم تكن حالة دفتر الأستاذ تالفة بالفعل (والتي سيتم اكتشافها بواسطة الإصدار الثابت من البرنامج).

المشكلة هي:

• يوجد إصداران من الوظيفة لتطبيق كتلة على حالة دفتر الأستاذ ؛ واحد بطيء يقوم بفحص كامل وسريع يقوم بإجراء عدد أقل من الفحوصات.
• نظرًا لأن db-sync يتم الحصول على كتل تم التحقق من صحتها بالفعل بواسطة العقدة ، فقد بدا من المنطقي استخدام الإصدار السريع.
• لقد قيل لي أن عمليات التحقق في الإصدار السريع تضمنت التحقق من أن تجزئة الكتلة السابقة تتطابق مع قيمة تجزئة الرأس في حالة دفتر الأستاذ ، ولكن لم يتم إجراء فحص التجزئة هذا.
• يسمح البروتوكول أحيانًا لأكثر من قائد فتحة واحدة بسك كتلة لفتحة معينة ، وستكون الكتل التي تنتجها تجزئات مختلفة (أي تتضمن الكتلة بيانات خاصة بقائد الفتحة).
• نظرًا لأنني أستخدم الإصدار السريع ويعود الكود الخاص بي إلى الفتحة المحددة ، فمن الممكن أن يتراجع إلى رقم الفتحة الصحيح ، ولكن الكتلة الخاطئة (أي رقم الفتحة صحيح ، ولكن تجزئة خاطئة وبالتالي كتلة خاطئة).
• عندما يتقدم الآن إلى الأمام ، يعني عدم وجود تدقيق التجزئة أن المشكلة لم يتم اكتشافها حتى بداية الحقبة التالية.

erikd هل من الممكن جعل هذا تبديل تكوين بين الفحص الكامل والفحص السريع؟ أفضل تشغيل كل شيء في الوضع "الآمن" واستخدام موارد إضافية للتأكد من استمراره.

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

رهيبة ، من الرائع سماعها! الطريقة التي تمت صياغتها بها بدت وكأن هناك الكثير مما يجري. لكن نعم ، لا تقلق تصادمات التجزئة.

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

يجب ألا يكون من الممكن الرجوع إلى رقم الفتحة الصحيح ، ولكن الكتلة الخاطئة.

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

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

لا ينبغي أن يكون من الممكن التراجع إلى رقم الفتحة الصحيح ، ولكن الكتلة الخاطئة.

من الممكن إذا كان التراجع يتحقق فقط من رقم الفتحة وليس التجزئة.

أنتج التسجيل الآن هذا:

[db-sync-node:Info:39] [2020-11-19 08:47:21.84 UTC] Rolling back to slot 8092720, 
        hash e1e78605937bb8cfc842d1ee7280b92fa9fce813c26fa66a88eaca74d7af9f05
[db-sync-node:Info:39] [2020-11-19 08:47:21.84 UTC] Deleting slots numbered: [8092760]
Ledger state hash mismatch. Ledger expects 6f1940937d806865a6e96b25a640deb8c1393852fd3d311dbd648e2bfa89056e
        but block provides e1e78605937bb8cfc842d1ee7280b92fa9fce813c26fa66a88eaca74d7af9f05. 

وهو أمر غريب بعض الشيء. تؤدي إعادة تشغيله إلى:
""
[db-sync- node: Info : 34] [2020-11-19 09: 06: 15.54 UTC] طرف قاعدة البيانات موجود في الفتحة 8092720 ، بلوك 389107
[db-sync- node: Info : 39] [2020-11-19 09: 06: 15.54 UTC] تشغيل مؤشر ترابط قاعدة البيانات
[db-sync- node: Info : 42] [2020-11-19 09: 06: 15.55 UTC] getHistoryInterpreter: تم الحصول عليه
[db-sync- node: Info : 39] [2020-11-19 09: 06: 15.55 UTC] العودة إلى الفتحة 8092720 ،
حجم التجزئة e1e78605937bb8cfc842d1ee7280b92fa9fce813c26fa66a88eaca74d7af9f05
[db-sync- node: Info : 39] [2020-11-19 09: 06: 15.56 UTC] حذف الفتحات المرقمة: []
""
تحتاج إلى التحقق من رمز لهذا.

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

إذا كان أي شخص يقوم بتشغيل الإصدار 6.0.0 وكان قلقًا بشأن بدء التمديد في غضون 12 ساعة تقريبًا ، فهناك فرع erikd/tmp-fix-6.0.x (الالتزام 3a6e7199c1f2) مع الحل البديل. يكتشف الحل البديل شيئًا ما في طريقه إلى الضلال ، والذعر ، وإعادة محاولة الإعفاء على مستوى أعلى ، ثم يستمر db-sync.

لا توجد تغييرات في قاعدة البيانات بالنسبة إلى 6.0.0 لذا لا يلزم إعادة المزامنة.

ومع ذلك ، فإن تشغيل هذا الإصدار قد يكتشف حالة دفتر الأستاذ تالفة بالفعل (لست متأكدًا حتى من الشكل الذي سيبدو عليه) وفي هذه الحالة ستكون إعادة المزامنة مطلوبة.

بعد إضافة مجموعة من كود التصحيح ثم الانتظار حتى يتم تشغيل المشكلة.

تبين أن هذه القضية هي حالة سباق. من السجلات:

[2020-11-21 08:27:09.90 UTC] insertShelleyBlock: epoch 230, slot 14380936, block 4978632,
    hash f984eead753a149efad752dd58471d0c53c3fcf973d281acf4fdcbc6fda799c7
[2020-11-21 08:27:34.22 UTC] insertShelleyBlock: epoch 230, slot 14380962, block 4978633,
    hash bfe35e62b322d397fa6c5080ccd8294c0d2eaca5695e604df59f27f82292227a
[2020-11-21 08:27:36.69 UTC] loadLedgerState: slot 14380962
    hash bfe35e62b322d397fa6c5080ccd8294c0d2eaca5695e604df59f27f82292227a
[2020-11-21 08:27:37.15 UTC] insertShelleyBlock: epoch 230, slot 14380964, block 4978634,
    hash 1ef4771244b95d35c59371521d19fc145646f89f28bf7a18c4f6c8d7485da2b3
[2020-11-21 08:27:40.01 UTC] Rolling back to slot 14380962,
    hash bfe35e62b322d397fa6c5080ccd8294c0d2eaca5695e604df59f27f82292227a
[2020-11-21 08:27:40.02 UTC] Deleting slots numbered: [14380964]
[2020-11-21 08:27:40.35 UTC] ChainSyncWithBlocksPtcl: FatalError {fatalErrorMessage = "Ledger state hash
    mismatch. Ledger head is slot 14380964 hash
    1ef4771244b95d35c59371521d19fc145646f89f28bf7a18c4f6c8d7485da2b3 but block previous hash is 
    bfe35e62b322d397fa6c5080ccd8294c0d2eaca5695e604df59f27f82292227a and block current
    hash is 136956bd1c6ce536e3c3bb0cef07b3e380441522317c88274f1455a7b11ca2d5."}
[2020-11-21 08:27:41.35 UTC] Starting chainSyncClient
[2020-11-21 08:27:41.36 UTC] Database tip is at slot 14380962, block 4978633
[2020-11-21 08:27:41.36 UTC] Running DB thread
[2020-11-21 08:27:41.54 UTC] Rolling back to slot 14380962,
    hash bfe35e62b322d397fa6c5080ccd8294c0d2eaca5695e604df59f27f82292227a
[2020-11-21 08:27:41.54 UTC] Deleting slots numbered: []
[2020-11-21 08:27:42.54 UTC] loadLedgerState: slot 14380962
    hash bfe35e62b322d397fa6c5080ccd8294c0d2eaca5695e604df59f27f82292227a

ما يحدث في الأساس هو:

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

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

تم الإصلاح على الماستر في https://github.com/input-output-hk/cardano-db-sync/pull/413 .

سيكون هناك أيضًا إصدار 6.0.1 لإصلاح ذلك.