दोबारा समाधान कराए बिना Python SDK की त्रुटियाँ संभालें

सिंक्रोनस Python SDK का solve मेथड टास्क एक बार बनाता है और उसके तैयार होने या त्रुटि उठने तक पोल करता है। 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 सुरक्षित रखें। यह मानने के बजाय कि निर्माण कभी हुआ ही नहीं, जो भी ID उपलब्ध हों उनका उपयोग करें।

उदाहरण रिकवरी की जानकारी प्रिंट करता है, लेकिन उसे स्थायी रूप से सेव नहीं करता और न ही रिकवरी करता है। ऐसे इंटीग्रेशन में जिसे प्रोसेस रीस्टार्ट के बाद भी काम जारी रखना हो, solve कॉल करने से पहले मूल टास्क इनपुट और अनुरोध ID सेव करें, फिर लौटाई गई किसी भी टास्क ID को सुरक्षित रखें। सेव किए गए उन इनपुट की सुरक्षा करें जिनमें प्रॉक्सी क्रेडेंशियल हैं।

1. 1.

   यदि आपके पास task_id है, तो get_task फिर शुरू करें

   दोबारा solve कॉल करने के बजाय वही टास्क प्राप्त करें। get_task टास्क ID और wait_ms आर्ग्युमेंट स्वीकार करता है; इसकी डिफ़ॉल्ट प्रतीक्षा 15000 मिलीसेकंड है। स्टेटस pending या solving रहने तक जारी रखें। समाधान का उपयोग केवल ready स्टेटस पर करें, और failed पर रुक जाएँ।

2. 2.

   यदि टास्क ID मिलने से पहले निर्माण बीच में रुक गया था, तो create_task दोबारा भेजें

   उसी requestId के साथ बिल्कुल वही टास्क इनपुट भेजें; ज़रूरत पड़ने पर रिकवर की गई request_id का उपयोग करें। उसी अनुरोध के साथ उस ID का दोबारा उपयोग करने से मौजूदा टास्क लौटता है; इनपुट बदलने से कॉन्फ़्लिक्ट होता है। उसकी टास्क ID मिलने के बाद get_task से आगे बढ़ें।

3. 3.

   रिकवरी के दौरान दूसरी ID जनरेट न करें

   उदाहरण solve कॉल करने से पहले अपना UUID जनरेट करता है। रिकवरी करते समय वही मान रखें; टास्क निर्माण दोबारा चलाकर अनजाने में उसे बदल न दें। नई ID एक अलग अनुरोध दर्शाती है, बीच में रुके अनुरोध का दोबारा प्रयास नहीं।

यदि आप requestId नहीं देते, तो SDK इसे जनरेट करता है, त्रुटियों में रिकवरी ID उपलब्ध कराता है और टास्क निर्माण का कभी अपने-आप दोबारा प्रयास नहीं करता। solve के दौरान, यह सॉल्व की समय-सीमा के भीतर अस्थायी पोलिंग विफलताओं के लिए Retry-After का पालन करता है। यदि कॉल फिर भी एक्सेप्शन उठाती है, तो दूसरा सॉल्व शुरू करने के बजाय सेव की गई ID से फिर शुरू करें।

ApiError के लिए, कुछ भी दोबारा भेजने का निर्णय लेने से पहले HTTP त्रुटि जाँचें। परिणाम अनिश्चित होने पर बीच में रुके निर्माण को रिकवर करना उचित है; बिना बदले अमान्य इनपुट को आँख मूँदकर दोबारा भेजना नहीं।

TaskFailedError के मामले में टास्क समाप्त हो चुका है। प्राप्त किए गए विफल टास्क में errorCode और error होते हैं; Python एक्सेप्शन कोड को error.error_code के रूप में उपलब्ध कराता है। क्या बदलना है, यह तय करने के लिए उस जानकारी का उपयोग करें। उदाहरण के लिए, site-unreachable होने पर लक्ष्य तक पहुँच की जाँच करनी चाहिए, न कि यह मान लेना चाहिए कि खाते में क्रेडिट नहीं है। विफल सॉल्व का शुल्क वापस किया जाता है।