שחזור בקשה שחרגה מהזמן הקצוב בלי לשלם על משימה נוספת
חריגה מזמן ההמתנה לחיבור לא אומרת שיצירת המשימה נכשלה. ייתכן ש-solvethree יצרה את המשימה לפני שהתגובה אבדה. כדי לשחזר אותה, שלחו את אותם נתוני קלט עם אותו requestId, במקום לשלוח משימה לוגית חדשה.
בדף הזה
שמרו את הבקשה ושלחו אותה שוב ללא שינוי
requestId מזהה משימה לוגית אחת לאורך ניסיונות היצירה. הוא מקבל 1–64 תווי ASCII: אותיות, ספרות, קווים תחתונים או מקפים. בחרו אותו לפני שליחת הבקשה ושמרו אותו עם נתוני הקלט המקוריים של המשימה.
- 1.
שמרו את גוף בקשת המשימה
הכניסו את הבקשה המלאה, כולל
requestId, לקובץrequest.json. עבור reCAPTCHA Enterprise, כללו אתsiteכשם מארח, אתaction, ובדיוק אחד מהשדותproxyאוproxyCandidates. אל תוסיפוtypeאוurl. שמרו את הקובץ פרטי, כי הוא מכיל פרטי גישה לפרוקסי. - 2.
שלחו את הקובץ השמור
הריצו את הפקודה הבאה עם מפתח ה-API של סביבת העבודה שלכם. שמרו את המפתח בשרת.
- 3.
אם החיבור חורג מזמן ההמתנה, הריצו שוב את הפקודה
השתמשו באותה פקודה בדיוק ובקובץ
request.jsonללא שינוי. אל תיצרו requestId נוסף ואל תשנו את נתוני הקלט של המשימה רק משום שהתגובה לא הגיעה.
# request.json contains one valid task body and a saved requestId.
# Keep the file private: it contains your proxy credentials.
curl --fail-with-body --max-time 30 \
'https://api.solvethree.com/v1/tasks?waitMs=0' \
-H "Authorization: Bearer $SOLVETHREE_API_KEY" \
-H 'Content-Type: application/json' --data-binary @request.json
# If the connection broke, run the identical command with the identical file.
# New task: HTTP 201. Same requestId + same inputs: HTTP 200, existing task.
# Same requestId + changed inputs: HTTP 409.HTTP 201 מציין שנוצרה משימה חדשה. HTTP 200 מציין שהבקשה הזהה שחזרה את המשימה הקיימת. בשני המקרים, קראו את מזהה המשימה ואת הסטטוס שהוחזרו; אף אחד מקודי סטטוס ה-HTTP האלה לא מעיד בפני עצמו שהפתרון מוכן.
כדוגמה מוחשית לשינוי קלט, נניח שבבקשה השמורה הערך של action הוא login. שינוי שלו ל-checkout תוך שמירה על אותו requestId מחזיר HTTP 409, התנגשות במזהה הבקשה. כדי לשחזר את המשימה המקורית, שחזרו את הקובץ המקורי ושלחו אותו שוב. אם אתם זקוקים בכוונה לנתוני הקלט ששונו, הקצו למשימה הלוגית החדשה requestId חדש.
טפלו בתגובות HTTP שאינן מציינות הצלחה לפני קריאת גוף תגובת הצלחה של משימה. 409 הוא שגיאה בבקשת HTTP, ולא כשל סופי של המשימה המקורית.
חלצו את המזהים משגיאת SDK
שתי ערכות ה-SDK הרשמיות מייצרות requestId אם לא ציינתם אותו, אך אף אחת מהן לא מנסה שוב באופן אוטומטי ליצור משימה. אם קריאת SDK זורקת חריגה, בדקו את שדות השחזור שלה לפני התחלת משימה נוספת.
- JavaScript:
SolvethreeErrorחושפת אתrequestIdואתtaskId. - Python:
SolvethreeErrorחושפת אתrequest_idואתtask_id.
אם השגיאה מכילה מזהה משימה, חדשו את התשאול באמצעות GET עבור המשימה הזאת; אין צורך לחזור על יצירתה. אם היא מכילה רק מזהה בקשה, שלחו שוב את בקשת היצירה עם אותו מזהה ועם נתוני הקלט המקוריים, ואז השתמשו במזהה המשימה שהוחזר. חשוב לשמור את נתוני הקלט המקוריים גם כאשר ה-SDK יצרה את המזהה.
אל תתייחסו לכל חריגה כאל יצירה שנקטעה. TaskFailedError מייצגת משימה שכבר הגיעה לסטטוס כשל סופי, ולא בקשה שדורשת שחזור.
המשיכו עם המשימה ששוחזרה
אחזרו את המשימה ששוחזרה באמצעות GET /v1/tasks/:id. המשיכו לתשאל כל עוד הסטטוס שלה הוא pending או solving. רק ready מכיל פתרון שניתן להשתמש בו.
אם הסטטוס הוא failed, הפסיקו לתשאל ובדקו את errorCode ואת error. ניתן החזר על פתרונות שנכשלו. זה שונה ממצב שבו אתר דוחה פתרון שנוצר: ready מציין שהפתרון זמין, ולא שאתר היעד קיבל אותו.
תוצאות שהושלמו עשויות להחזיר HTTP 410 לאחר שתקופת השמירה מסתיימת, ולכן שחזור אינו אחסון קבוע של תוצאות. למידע על לולאת התשאול עצמה, ראו תשאול משימות וזמני המתנה.
מקורות ותיעוד API
עדיין לא הסתדר?
יש לשלוח לתמיכה את מזהה המשימה ואת השגיאה שהתקבלה.