معالجة أخطاء حزمة SDK لـ Python دون تكرار عمليات الحل

تنشئ الطريقة solve في حزمة SDK المتزامنة لـ Python مهمة مرة واحدة وتستطلع حالتها حتى تصبح جاهزة أو تطرح خطأ. التقط الاستثناءات المحددة قبل SolvethreeError لتتمكن من التمييز بين فشل الحل وانقطاع طلب HTTP.

اضبط SOLVETHREE_API_KEY وSOLVETHREE_PROXY، ثم استبدل اسم المضيف والإجراء في المثال بالقيم الخاصة بهدفك. يحتاج الموقع إلى ملف تعريف نشط في مساحة العمل قبل التمكن من حل تحدياته.

import os
import uuid
from solvethree import Solvethree, ApiError, TaskFailedError, SolvethreeError

client = Solvethree(os.environ["SOLVETHREE_API_KEY"])
task = {"site": "accounts.example.com", "action": "login", "proxy": os.environ["SOLVETHREE_PROXY"], "requestId": str(uuid.uuid4())}
try:
    result = client.solve(task, timeout=180)
    print("Ready task:", result["id"])
    # Submit result["solution"] privately through the target application.
except TaskFailedError as error:
    print("Failed task:", error.task_id, "code:", error.error_code)
    # This task is terminal. Inspect it before starting different work.
except ApiError as error:
    print("HTTP status:", error.status, "retry delay:", error.retry_after)
    print("Recovery IDs:", error.request_id, error.task_id)
    # A known task_id means resume get_task; otherwise replay the exact task
    # with error.request_id. Do not generate a new logical request to recover it.
except SolvethreeError as error:
    print("Recovery IDs:", error.request_id, error.task_id)
    # Save these IDs and the original task inputs for explicit recovery.

• TaskFailedError: وصلت المهمة إلى الحالة النهائية failed. افحص error.task_id وerror.error_code؛ ولا تواصل استطلاع تلك المهمة.
• ApiError: فشل طلب HTTP. افحص error.status وerror.retry_after، الذي يُقاس بالثواني. هذا ليس مماثلًا لفشل المهمة النهائي.
• SolvethreeError: احتفظ بـ error.request_id وerror.task_id للاسترداد الصريح. استخدم المعرّفات المتاحة بدلًا من افتراض أن الإنشاء لم يحدث أصلًا.

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

1. 1.

   إذا كان لديك task_id، فاستأنف get_task

   استرجع تلك المهمة بدلًا من استدعاء solve مجددًا. يقبل get_task معرّف المهمة ووسيطة wait_ms؛ ومدة الانتظار الافتراضية هي 15000 مللي ثانية. واصل ما دامت الحالة pending أو solving. استخدم الحل فقط عندما تكون الحالة ready، وتوقف عند failed.

2. 2.

   إذا انقطع الإنشاء قبل استلام معرّف مهمة، فأعد إرسال create_task

   أرسل مدخلات المهمة المطابقة باستخدام requestId نفسه، مستعينًا بـ request_id المسترد عند الحاجة. إعادة استخدام ذلك المعرّف مع الطلب نفسه تعيد المهمة الموجودة؛ أما تغيير المدخلات فيسبب تعارضًا. بمجرد حصولك على معرّف المهمة، واصل باستخدام get_task.

3. 3.

   لا تنشئ معرّفًا آخر أثناء الاسترداد

   ينشئ المثال UUID قبل استدعاء solve. احتفظ بتلك القيمة عند الاسترداد؛ ولا تُعد تشغيل بناء المهمة فتستبدلها عن طريق الخطأ. المعرّف الجديد يمثل طلبًا منفصلًا، لا إعادة محاولة للطلب الذي انقطع.

تُنشئ حزمة SDK قيمة requestId إذا أغفلتها، وتتيح معرّفات الاسترداد ضمن الأخطاء، ولا تعيد محاولة إنشاء المهمة تلقائيًا أبدًا. أثناء solve، تلتزم بـ Retry-After عند حدوث إخفاقات مؤقتة في الاستطلاع ضمن مهلة الحل. إذا ظل الاستدعاء يطرح خطأ، فاستخدم المعرّفات المحفوظة للاستئناف بدلًا من بدء عملية حل أخرى.

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

في حالة TaskFailedError، تكون المهمة قد انتهت. تتضمن المهمة الفاشلة المسترجعة errorCode وerror؛ ويتيح استثناء Python الرمز عبر error.error_code. استخدم هذه المعلومات لتحديد ما يجب تغييره. على سبيل المثال، يستدعي site-unreachable التحقق من إمكانية الوصول إلى الهدف، لا افتراض أن الحساب يفتقر إلى الرصيد. يُردّ رصيد عمليات الحل الفاشلة.