لغز المهام الطويلة في A2A: لماذا تفشل المهام التي تتجاوز دقيقتين؟

هيرميس على جهازين يتصلان ببعضهما “هاتفيًا” لتبادل المهام، وأي مهمة تتجاوز دقيقتين تفشل — مهما عدّلت الإعدادات. هذا ليس أمرًا غامضًا، بل ثلاثة عوائق متراكمة.

اللغز: لعنة الدقيقتين

تخيل أنك تطلب من زميلك “أ” معالجة ملف، وتتفقان على أنه بعد الانتهاء سيتصل بك ليخبرك بالنتيجة. لكن في كل مرة يتجاوز فيها الاتصال دقيقتين، ينقطع الخط من طرفك فجأة، وتظهر رسالة “فشل الاتصال”. جرّبت تغيير الهاتف، وتغيير الخط، وحتى الانتقال إلى مكتب آخر، والمشكلة ما زالت قائمة.

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

السبب الأول: المتصل قليل الصبر

العائق الأول هو مشكلة “نفاد الصبر” الخالصة.

عميل هيرميس لديه إعداد افتراضي لمهلة الانتظار — 120 ثانية. ماذا يعني ذلك؟ يعني أن المتصل يضبط لنفسه منبهًا: إذا لم يرد الطرف الآخر خلال 120 ثانية، سأقطع الاتصال. لكن ماذا عن الخادم؟ هو يخصص نافذة رد تصل إلى 300 ثانية، أي 5 دقائق، ليقوم الوكيل بإنجاز المهمة.

كما ترى، المتصل يقطع بعد دقيقتين، بينما المستقبِل يظن أن لديك صبرًا لخمس دقائق. النتيجة: المهمة ما زالت قيد التنفيذ، والاتصال انقطع أولًا. والأسوأ أن هذه المهلة البالغة 120 ثانية مكتوبة بشكل ثابت في الكود البرمجي، والمستخدم العادي لا يجد مكانًا لتعديلها حتى لو أراد.

السبب الثاني: الخط القديم بلا مفتاح “مهلة”

العائق الثاني هو إرث تاريخي.

هيرميس يوفر طريقتين لاستدعاء A2A: الأولى هي “تحويل عبر السنترال” الرسمي (الاستدعاء عبر الأقران المُعدّين)، والثانية هي “الخط المباشر القديم” (الاستدعاء مباشرة عبر URL الأصلي). الخط القديم جاء من إصدارات سابقة، وهو يضم أيضًا مهلة 120 ثانية مكتوبة بشكل ثابت، ولا يقرأ ملف الإعدادات.

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

السبب الثالث: التخلص من النتيجة عند انتهاء المهلة

العائق الثالث هو الأخطر: الخادم “يكنس المكان” عند انتهاء المهلة.

لنفترض أنك نجحت أخيرًا في تكبير مهلة العميل، وتجاوزت العائقين الأولين. عندها يظهر عائق جديد من جهة الخادم: بمجرد انتهاء نافذة الرد البالغة 300 ثانية، يقوم بتعليم المهمة على أنها “فاشلة”، حتى لو كان الوكيل ما زال يعمل بجد. والأسوأ من ذلك، أن حالة “الفشل” هذه لاصقة — مثل الغراء لا يمكن التخلص منها. وعندما ينهي الوكيل المهمة فعلًا ويعود بالنتيجة، يجد أنه لا أحد ينتظره، فتُهمَل النتيجة مباشرة.

هذا يشبه عامل توصيل يغادر في نهاية دوامه، بغض النظر عما إذا كانت طردك قد وصل أم لا، فيظهر النظام أولًا “فشل التوصيل”. وفي اليوم التالي عندما تستلم الطرد، تبقى معلومات التتبع عالقة في خانة “فشل” إلى الأبد، ولا يمكن تغييرها.

الخطوة الأولى لحل اللغز: إبطاء المنبه

بمجرد فهم العوائق الثلاثة، يصبح الإصلاح سهلًا.

الإصلاح الأول واضح ومباشر: تغيير مهلة العميل الافتراضية من 120 ثانية إلى 330 ثانية. بما أن 330 ثانية > 300 ثانية (مهلة الخادم)، يصبح المتصل أكثر صبرًا من المستقبِل، وبذلك تتمكن المهمة من تجاوز نافذة الرد الخاصة بالخادم. وفي الوقت نفسه، أضيفت معلمة per-call لتجاوز المهلة في a2a_call — يمكنك الآن ضبط مهلة زمنية لمهمة فردية بشكل منفصل، دون الحاجة لتغيير عام. كما أن الخط القديم “تحدّث أخيرًا”، فأصبح يقرأ الإعدادات، ويرث إعدادات المصادقة والمهلة.

الخطوة الثانية لحل اللغز: “فصل” المهمة بدلًا من “فشلها”

الإصلاح الثاني أكثر ذكاءً. لم يعد الخادم يعلّم المهمة على أنها “فاشلة” عند انتهاء المهلة، بل يقوم “بفصلها”. ماذا يعني ذلك؟ الأمر مثل الانتظار في خط خدمة العملاء: إذا طال الانتظار ولم تعد ترغب في الانتظار، يمكنك إنهاء المكالمة، لكن تذكرتك ما زالت في النظام، وستصلك رسالة نصية عند اكتمال المعالجة.

بالتحديد: عند انتهاء نافذة الرد، يتلقى المتصل حالة غير نهائية تعني “قيد العمل”، مع إرشادات مرافقة. تبقى المهمة في حالة WORKING، ويُعيَّن “منتظر محدود” لمواصلة المراقبة. وعندما ينهي الوكيل المهمة فعلًا، تُسجَّل النتيجة الحقيقية. وبعد ذلك، سواء استُعلم عبر tasks/get أو tasks/resubscribe، سيتمكن المراقبون من رؤية النتيجة النهائية. النتائج المتأخرة لم تعد تُهمَل.

الخطوة الثالثة لحل اللغز: إصلاحات إضافية بالمناسبة

بعد حل القضية الرئيسية، اكتُشفت أيضًا بعض العيوب المجاورة.

اقتطاع الردود المتدفقة: سابقًا، كانت الردود المتدفقة قد تُرجع الجزء الأخير فقط للمتصل. مثلًا، سلسلة event_id طويلة تُقتطع ليبقى الجزء الثاني فقط، فيحصل المتصل على معلومات ناقصة. بعد الإصلاح، تُحفظ الردود المتراكمة كاملةً، واجتازت جميع حالات الاختبار البالغ عددها 152 حالة.

الاكتمال الزائف: عندما ينفد ميزان التكرار للوكيل، كان يُرجع سابقًا ملخصًا “مكتملًا”، لكن الطرف المقابل لا يستطيع التمييز بين “عمل مبتور” و“عمل مكتمل بنجاح”، وقد يقبل النتيجة الجزئية على أنها كاملة. الآن، المهام المبتورة تُبلّغ بوضوح عن TASK_STATE_FAILED، ولم تعد تتظاهر بالنجاح.

المشغّل الخارجي: يمكن للمستخدمين غير الجذرين الآن تكوين مشغّل وكلاء خارجي، لتشغيل عمليات فرعية أو عمال RPC بنسخ محددة، مع دعم الإخراج المحدود، وجمع شجرة العمليات، والإلغاء، والإنهاء لمرة واحدة بالضبط. هذا يحل ثلاث مشاكل قديمة: رؤية الاكتمال، ومزامنة المهلة، واستمرارية الجولات المتعددة.

ماذا يعني هذا بالنسبة لك

الآن، عند تبادل المهام بين جهازي هيرميس، لم تعد المهام التي تتجاوز دقيقتين “تفشل حتمًا”. مهلة الانتظار قابلة للتعديل، والخط القديم أصبح مطيعًا. والأهم من ذلك، حتى لو نفد صبر الخادم، لن تُحكم على المهمة “بالإعدام” — بل ستبقى في حالة عمل، وعند الانتهاء تُسجَّل النتيجة بشكل طبيعي، ويمكنك الاستعلام عنها في أي وقت.

أصبحت المهام الطويلة أخيرًا مثل الجري لمسافات طويلة: هناك من يضبط الوقت، ومن يرافقك في الجري، ومن يسجّل النتيجة. بدلًا من أن تكون كما كانت سابقًا: تقطع في منتصف الطريق بسبب صافرة الحكم، وتُلغى النتيجة.