दूसरे कार्य का भुगतान किए बिना टाइमआउट हुए अनुरोध को रिकवर करें

एक requestId टास्क बनाने के अलग-अलग प्रयासों में एक ही लॉजिकल टास्क की पहचान करता है। इसमें 1–64 ASCII अक्षर, अंक, अंडरस्कोर या हाइफ़न हो सकते हैं। अनुरोध भेजने से पहले इसे चुनें और मूल टास्क इनपुट के साथ रखें।

1. 1.

   टास्क बॉडी सहेजें

   requestId सहित पूरा अनुरोध request.json में रखें। reCAPTCHA Enterprise के लिए, site में होस्टनेम, action, और proxy या proxyCandidates में से ठीक एक शामिल करें। type या url न जोड़ें। फ़ाइल को निजी रखें क्योंकि इसमें प्रॉक्सी क्रेडेंशियल हैं।

2. 2.

   सहेजी गई फ़ाइल भेजें

   अपने वर्कस्पेस की API कुंजी के साथ नीचे दिया गया कमांड चलाएँ। कुंजी को सर्वर पर रखें।

3. 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 का मतलब है कि उसी अनुरोध से मौजूदा टास्क रिकवर हुआ। दोनों ही मामलों में लौटाई गई टास्क ID और स्थिति पढ़ें; केवल किसी भी HTTP स्थिति का मतलब यह नहीं है कि समाधान तैयार है।

बदले हुए इनपुट के ठोस उदाहरण के लिए, मान लें कि सहेजे गए अनुरोध में action का मान login है। उसी requestId को रखते हुए इसे checkout में बदलने पर HTTP 409, यानी अनुरोध ID का टकराव मिलता है। मूल टास्क रिकवर करने के लिए, मूल फ़ाइल बहाल करके उसे दोबारा भेजें। अगर आपको जानबूझकर बदले हुए इनपुट चाहिए, तो उस नए लॉजिकल टास्क को नया requestId दें।

टास्क की सफलता का पेलोड पढ़ने से पहले असफल HTTP प्रतिक्रियाओं को संभालें। 409 एक HTTP अनुरोध त्रुटि है, मूल टास्क की अंतिम विफलता नहीं।

अगर आप requestId नहीं देते, तो दोनों आधिकारिक SDK इसे बनाते हैं, लेकिन कोई भी टास्क बनाने का प्रयास अपने-आप दोबारा नहीं करता। अगर SDK कॉल अपवाद फेंकता है, तो दूसरा टास्क शुरू करने से पहले उसके रिकवरी फ़ील्ड देखें।

• JavaScript: SolvethreeError में requestId और taskId उपलब्ध होते हैं।
• Python: SolvethreeError में request_id और task_id उपलब्ध होते हैं।

अगर त्रुटि में टास्क ID है, तो उस टास्क के लिए GET पोलिंग फिर शुरू करें; उसे दोबारा बनाने की ज़रूरत नहीं है। अगर उसमें केवल अनुरोध ID है, तो उस ID और मूल इनपुट के साथ बनाने का अनुरोध दोबारा भेजें, फिर लौटाई गई टास्क ID इस्तेमाल करें। SDK ने ID बनाई हो, तब भी मूल इनपुट रखना ज़रूरी है।

हर अपवाद को टास्क बनाने में आई रुकावट न मानें। TaskFailedError ऐसे टास्क को दर्शाता है जो पहले ही अंतिम विफल स्थिति में पहुँच चुका है, न कि ऐसे अनुरोध को जिसे रिकवर करना है।

GET /v1/tasks/:id से रिकवर किया गया टास्क प्राप्त करें। जब तक उसकी स्थिति pending या solving है, पोलिंग जारी रखें। केवल ready में इस्तेमाल करने योग्य समाधान होता है।

अगर स्थिति failed है, तो पोलिंग रोकें और errorCode व error देखें। विफल समाधान प्रयासों का शुल्क वापस किया जाता है। यह किसी वेबसाइट के जनरेट किए गए समाधान को अस्वीकार करने से अलग है: ready का मतलब है कि समाधान उपलब्ध है, न कि लक्ष्य ने उसे स्वीकार कर लिया है।

रिटेंशन अवधि समाप्त होने के बाद पूरे हो चुके परिणाम HTTP 410 लौटा सकते हैं, इसलिए रिकवरी परिणामों का स्थायी भंडारण नहीं है। पोलिंग लूप के लिए, टास्क पोलिंग और टाइमआउट देखें।