טיפול בשגיאות 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 מחייב לבדוק את הנגישות ליעד, ולא להניח שאין יתרה בחשבון. התשלום על פעולות פתרון שנכשלו מוחזר.