عشر عمليات نشر يوميًا. إحداها سيئة. تجدها Polylane وتتراجع عنها.
انضم إلى قائمة الانتظاركل عملية نشر تُراقَب، من دون إعداد. ما الذي تغيّر، ومن غيّره، والإشارات الأرجح أن تتعطل.
SQS visibility timeout lowered on checkout-events
VisibilityTimeout on checkout-events dropped from 120s to 15s. Consumers that hold a message longer than 15 seconds will see it delivered twice; the dead-letter queue threshold is unchanged.
SetQueueAttributes CloudTrail · deploy-bot · 12:41:02Z attached to this record's delta window التراجع، إن أردته. معطّل افتراضيًا. فعّله، ويتولى وكيل البقية.
Critical latency degradation in checkout-edge worker
checkout-edge › Cloudflare Worker Critical latency degradation detected in checkout-edge worker: 18x+ P99 latency spikes sustained for 12 minutes
edge-gateway Cloudflare Worker ··· checkout-edge Cloudflare Worker ··· 
hd-prod Hyperdrive ··· 
payments-db PlanetScale ··· cart-svc Cloudflare Worker ···
Deploy 9f3c2a1 shrank the Hyperdrive pool
hd-prod from 50 connections to 5. Under checkout load,
requests queue on connection checkout and P99 rises 18× against the 30-minute baseline. Restoring the pool size restores latency.
تراجع الآن. وأصلح كما ينبغي بعد ذلك. التراجع يكسب الوقت: والإصلاح الحقيقي يتبعه لمراجعتك.
Cap retries on the checkout webhook worker #491
polylanemain from polylane/autofix/chat/k3x9f2-4e7d21a 
Retries on the checkout webhook worker were unbounded: a failing delivery re-queued itself forever and amplified load on payments-api. This caps delivery at 5 attempts with exponential backoff and dead-letters the payload after the last one.
What changed
worker/deliver.ts gains MAX_DELIVERY_ATTEMPTS = 5 and backoff between attempts; exhausted payloads land in checkout-webhooks-dlq instead of re-queueing.
Validation
npm test — 214 passed. A forced failing delivery stopped after 5 attempts and appeared in the dead-letter queue.
كيف تعمل Polylane. تتعلم نظامك، وتراقبه، وتحقق، وتتصرف.
-
تتعلم نظامك أولًا
يرسم مخطط السياق كل مورد وكل تبعية عبر سحاباتك ومستودعاتك ومزودي قابلية الملاحظة لديك. ويستنتج الوكلاء من Topology حقيقية، لا من تخمينات.
-
اكتشاف من دون عتبات
فحوصات مدمجة لكل مزود، إضافة إلى فحوصات مولّدة من استعلاماتك المحفوظة ولوحات معلوماتك. تقرر مرحلة إحصائية ووكيل معًا، والتحسّن لا يفتح مشكلة أبدًا.
-
تحقيقات تُظهر الإثباتات
كل ادعاء يرتبط بالاستعلام أو سطر السجل أو سجل التغيير الذي يقف خلفه. والحكم بلا دليل يعود إلى غير حاسم.
-
الكتابة تُكتسب، ولا تُفترض أبدًا
تُربط الحسابات للقراءة فقط. وعمليات التراجع معطّلة افتراضيًا، وبمعدل محدود، ومسجّلة. وتمر تغييرات الكود عبر مراجعتك المعتادة.
-
تصير أدق كل أسبوع
ذكريات وملاحظات يومية واستعلامات مراقبة يُعاد تأكيدها مقابل بيانات حقيقية: تحقيق يوليو يتعلم من تحقيق يونيو.
تتصل بما تشغّله أصلًا. اربط للقراءة فقط وابدأ.
أسئلة.
على أي المنصات تستطيع Polylane التراجع؟
عمليات النشر على Cloudflare وVercel وRender وFly.io، باستعادة آخر عملية نشر معروفة بسلامتها. وعمليات التراجع معطّلة افتراضيًا: تفعّلها بنفسك ويمكنك إيقافها في أي وقت.
ما الذي يمنع حلقة تراجع تلقائية؟
حدود صارمة في المنصة، لا حكم الوكيل. ثلاث عمليات تراجع ناجحة في الساعة لكل هدف، وعملية تراجع واحدة جارية في كل مرة، وعندما تختلف المسارات المتوازية على الإصدار الذي يُستعاد، يُحجب الإجراء ويُصعَّد إليك.
هل تحتاج إلى pipeline CI الخاص بي؟
لا. تقرأ Polylane عمليات النشر من المزودين أنفسهم. وتجري مراجعة طلبات pull request بصفتها فحص GitHub يمكنك جعله إلزاميًا، لكن لا شيء في pipeline الخاص بك يتغيّر.
ماذا عن التغييرات التي ليست عمليات نشر؟
تُسجَّل تعديلات الإعدادات وأحداث التوسّع والتغييرات الأمنية وتُراقَب بالطريقة نفسها. وعندما يسيء طابور التصرف بعد اثنتي عشرة دقيقة من تخفيض أحدهم مهلة الظهور فيه، يبدأ التحقيق من ذلك التغيير.
هل يمكنني معرفة سبب حدوث تراجع؟
كل تراجع له إثبات: الجولة التي أجرته، والإشارات التي تراجعت، والإصدار المستعاد، والتعليل، كلها تقع في السجل.