انتقل إلى المحتوى
use-cases / recurring-webhook-replay / hero
CRON · FILES · EXEC

أعِد تشغيل webhooks هذا الصباح في الوقت نفسه غداً

وجِّه webhook الإنتاج الحقيقيّ لـ Stripe إلى رابط hoody-files لمدّة ثلاثين دقيقة. المجلّد الآن يحوي أربعة عشر ملفّ JSON — كلّ حمولة وصلت إلى الإنتاج، بايت بايت. مدخل cron واحد يشغّل سكربت exec يُرسل POST بهذه الحمولات إلى staging في الساعة 9 صباحاً، من الإثنين إلى الجمعة. الجدول ينتهي يوم السبت القادم ويحذف نفسه.

اقرأ Cron API
use-cases / recurring-webhook-replay / pipeline

التقط مرّة، أبقِ كملفّات، أعِد التشغيل وفق جدول

التدفّق كلّه ثلاثة روابط. حركة الإنتاج تصل على رابط الالتقاط. الملفّات تهبط في hoody-files. cron يمرّ على المجلّد ويُرسل POST بالحمولات إلى staging. لا وسيط، لا قائمة انتظار، لا خدمة إعادة تشغيل — مجرّد مجلّد وجدول.

PIPELINEلا وسيط · لا قائمة انتظار
01 · CAPTURE

webhook الإنتاج يصبح PUT

اضبط رابط webhook الخاصّ بـ Stripe / Intercom / GitHub على مسار hoody-files. كل حدث يصل كـ PUT ويهبط كملفّ JSON مُسمّى بطابعه الزمنيّ. المجلّد هو التسجيل.

02 · PERSIST

مجلّد لكل يوم، يمكن عنونته كرابط

الملفّات تبقى على القرص؛ كل ملفّ له رابطه الخاصّ. تصفّح المجلّد في متصفّح، اعرضه عبر الـ API، أو ادخل إليه بـ curl. التسجيل حقيقة يمكنك cat أو scp أو وضعها في إصدار.

03 · REPLAY

مدخل cron واحد يمشي على المجلّد

أرسل POST بمدخل cron مُدار بجدول 0 9 * * 1-5 وأمر bash /scripts/replay.sh /webhooks/2026-05-03. السكربت يُعدّد المجلّد ويُرسل POST بكل ملفّ إلى staging بترتيب الطوابع الزمنيّة.

الالتقاط والإعادة هما البروتوكول نفسه في يومين مختلفين. الشيء الذي سجّل البايتات هو الشيء الذي يُعيد تشغيلها. لا محلّل JSONL، لا sidecar، لا صيغة تسجيل عليك تعلّمها — ملفّات في مجلّد بترتيب زمنيّ.

use-cases / recurring-webhook-replay / mechanism

طلبا POST ومجلّد

الالتقاط هو PUT واحد لكل حدث webhook. الإعادة هي POST واحد إلى Cron API. Hoody Files تحفظ التسجيل؛ Hoody Cron يمرّ عليه وفق الجدول؛ hoody-exec يشغّل سكربت bash الذي يُجري POSTات. ثلاث خدمات بلا غراء بينها.

stripe → hoody-files
PUT · capture
# point your real webhook at hoody-files
curl -X PUT \
  https://files.containers.hoody.com/webhooks/2026-05-03/stripe-08-15-22.json \
  --data-binary @-

# 30 minutes later, the directory holds 14 files
HTTP/1.1 201 Created
webhooks/2026-05-03/stripe-08-15-22.json
اجدول الإعادة
POST · cron entry
# one cron entry replays the morning at 9am, mon-fri
curl -X POST \
  https://cron.containers.hoody.com/api/v1/cron/users/me/entries \
  -d '["schedule":"0 9 * * 1-5","command":"bash /scripts/replay.sh /webhooks/2026-05-03","expires_at":"2026-05-10T09:00:00Z"]'

HTTP/1.1 201 Created
{ "id":"f0a8", "schedule":"0 9 * * 1-5", "expires_at":"2026-05-10T09:00:00Z" }

جانب الالتقاط يعمل مرّة واحدة صباح الجمعة. جانب الإعادة يعمل كل يوم من أيام الأسبوع حتى السبت القادم، حين يحذف حقل expires_at الجدول. كتبتَ رابط PUT واحداً في إعدادات webhook، وPOST واحداً في Cron API — هذا هو اختبار الحمل بأكمله.

use-cases / recurring-webhook-replay / powers

ما يمنحك إيّاه هذا ولا يستطيعه ثابت اختبار حمل

الحركة الاصطناعيّة هي ما تخيّلتَ أن الطلب يبدو كذلك. الحركة الملتقطة هي ما وصل فعلاً. أسماء الحقول نفسها، الحالات الحدّيّة نفسها، المفاجآت نفسها.

FIDELITY

أشكال حمولة حقيقيّة، لا تخمينك

التسجيل يلتقط JSON الذي أرسله Stripe بدقّة — بما في ذلك كل حقل قابل للقيمة الفارغة، وكل نوع حدث غير متوقَّع، وكل تنسيق customer_id نسيتَه. مُعالِجك يلتقي بالحمولات نفسها التي فشل عليها بالأمس.

TIMING

الضغط نفسه من الوقت كما في الإنتاج

تعبير cron 0 9 * * 1-5 يُنزل الإعادة في الساعة التي يستخدم فيها مستخدموك الحقيقيّون النظام فعلاً. المُعالِج تحت الاختبار يرى ازدحام الصباح أمام ذاكرات التخزين المؤقّت ذاتها وجيران cron ذاتهم وقاعدة البيانات الصاخبة ذاتها.

REPEATABILITY

أعِد التشغيل حتى يختفي الخلل

المجلّد غير قابل للتغيير؛ cron يعمل كل يوم من أيام الأسبوع حتى expires_at. إن ظلّ المُعالِج يكسر في تشغيل الثلاثاء، تُصلحه وتدع تشغيل الأربعاء يُثبت ذلك. المدخل ذاته في كل مرّة — المُعالِج هو الشيء الوحيد الذي يتغيّر.

use-cases / recurring-webhook-replay / capacity

ما يَعِد به الجدول

الأرقام تأتي من واجهة Hoody Cron للمداخل المُدارة ومن مواصفات تعبير cron القياسيّ — لا من اختبارات أداء مُختلَقة.

  1. FIELDS PER ENTRY5

    تعبير cron معياريّ من 5 حقول — الدقيقة، الساعة، يوم الشهر، الشهر، يوم الأسبوع. الصيغة ذاتها التي استخدمتها في 1985 ما زالت تجدول الإعادة في 2026.

  2. ENTRIES PER PAGE200

    GET /users/[user]/entries يُرقّم حتى 200 مدخل مُدار في كل مرّة. ثلاث وستّون جدول إعادة لكل بيئة في الميزانية بسهولة.

  3. POST TO CREATE1

    أنشئ الإعادة المتكرّرة بـ POST واحد إلى /users/me/entries — جدول، أمر، expires_at. PATCH لاحقاً لكتمها؛ DELETE لإزالتها؛ expires_at يُزيلها عنك.

حدود وفق واجهة Hoody Cron Managed Entries: تعبيرات cron معياريّة من 5 حقول إضافةً إلى ماكروات @daily / @hourly، ترقيم حتى 200 مدخل لكل صفحة، expires_at اختياريّ ويُعطّل المدخل تلقائياً بعد الموعد.

use-cases / recurring-webhook-replay / punchline

حركة إنتاج، مُسجَّلة مرّة، مُعاد تشغيلها وفق جدول.

ملتقَطة · الجمعة 08:00مُعاد تشغيلها · من الإثنين إلى الجمعة 09:00
ما كان يبدو عليه اختبار الحمل القديمk6 script · faker · imagined payload shapesتخمينك لما يُرسله stripe · يُعاد تخمينه كل ربع
ما يبدو عليه الآنPUT files/webhooks/[day] · POST cron/entries 0 9 * * 1-5بايتات حقيقيّة وصلت إلى الإنتاج · مُعاد تشغيلها بجدول واحد
اقرأ Cron API
use-cases / recurring-webhook-replay / replaces

ما يحلّ هذا محلّه

الأدوات المعتادة لإعادة تشغيل حركة webhook — مُسجِّلات، خدمات إعادة، محاكيات مجدولة. كلّ منها SaaS أو sidecar أو سكربت ترعاه. ثنائيّ hoody-files + hoody-cron ليس أيّاً من هذه.

  • ngrok webhook recordingخطّة SaaS لتسجيل طلبات يمكنك كتابتها على القرص
  • Hookdeck event replaysخدمة توجيه أحداث لما هو مجرّد ملفّات في مجلّد
  • custom replay scriptsغراء تكتبه مرّة وتنسى كيف تجدوله
  • Postman scheduled mocksمقعد مراقِب لإطلاق HTTP على staging الخاصّ بك
  • خوادم النمذجة في بيئات الاختبارخلفيّة ثانية لصيانتها بجانب الحقيقيّة
  • manual webhook fuzzingأنت في الطرفيّة في الساعة 9 صباحاً تلصق حمولات
use-cases / recurring-webhook-replay / cta

التقط حركة الجمعة. اجدول إعادة الأسبوع القادم. دع مدخل cron ينتهي بنفسه حين تنتهي التجربة.

اقرأ Cron API
use-cases / recurring-webhook-replay / related

اقرأ الآخرين