CAPTCHA कार्य की पोलिंग और टाइमआउट संभालें

waitMs तय करता है कि API अनुरोध रिस्पॉन्स देने से पहले परिणाम के लिए कितनी देर प्रतीक्षा करेगा। यह URL क्वेरी पैरामीटर है, टास्क JSON का फ़ील्ड नहीं। टास्क बनाते समय डिफ़ॉल्ट उत्पाद के अनुसार अलग होते हैं; GET पोलिंग की अपनी सीमा है।

HTTP क्लाइंट को अनुरोधित सर्वर प्रतीक्षा और नेटवर्क ओवरहेड के लिए पर्याप्त समय दें। सर्वर प्रतीक्षा से छोटा क्लाइंट टाइमआउट, टास्क की वर्तमान स्थिति मिलने से पहले रिस्पॉन्स को बाधित कर सकता है।

आधिकारिक SDK का solve मेथड एक बार टास्क बनाता है और तैयार परिणाम या त्रुटि मिलने तक पोलिंग करता है। Python में timeout और poll_interval सेकंड में दिए जाते हैं; Node.js में timeoutMs और pollIntervalMs मिलीसेकंड में दिए जाते हैं। दस्तावेज़ में दी गई सेटिंग हल करने के लिए तीन मिनट की समय-सीमा और एक सेकंड का पोलिंग अंतराल उपयोग करती हैं।

सीधे नियंत्रण के लिए Python में create_task और get_task हैं; Node.js में createTask और getTask हैं। इस क्रम का पालन करें:

1. 1.

   समय-सीमा तय करें और एक टास्क बनाएँ

   टास्क बनाने से पहले कुल समय-सीमा चुनें। टास्क के हूबहू इनपुट के साथ requestId रखें, ताकि टास्क बनाते समय प्रक्रिया बाधित होने पर उसे रिकवर किया जा सके। बनाते समय प्रतीक्षा से बचने के लिए स्पष्ट रूप से शून्य प्रतीक्षा चुनें।

2. 2.

   लौटाई गई टास्क ID सहेजें और उसकी स्थिति जाँचें

   टास्क बनाने पर ही अंतिम परिणाम मिल सकता है। ready होने पर समाधान लौटाएँ। failed होने पर errorCode और error जाँचें और रुक जाएँ; विफल समाधानों का भुगतान वापस किया जाता है। केवल pending और solving के लिए आगे पोलिंग चाहिए।

3. 3.

   समय रहते उसी टास्क को प्राप्त करते रहें

   GET /v1/tasks/:id का उपयोग करें; चाहें तो अधिकतम 15000 ms की लॉन्ग-पोल प्रतीक्षा रखें। सफलता वाला पेलोड पढ़ने से पहले असफल HTTP रिस्पॉन्स संभालें। अगर रिस्पॉन्स में अब भी pending या solving हो, तो उसी ID पर दोबारा अनुरोध करें—दूसरा टास्क बनाकर नहीं।

4. 4.

   समय-सीमा पर रुक जाएँ

   नेटवर्क ओवरहेड की गुंजाइश रखते हुए हर अनुरोध को बचे हुए समय तक सीमित रखें। समय-सीमा समाप्त होने पर स्थानीय लूप रोक दें और रिकवरी के लिए टास्क ID बनाए रखें। सिर्फ़ इसलिए टास्क को विफल न कहें कि आपके क्लाइंट ने प्रतीक्षा बंद कर दी।

यह अनुरोध मौजूदा टास्क प्राप्त करता है, जिसमें सर्वर को 15 सेकंड की प्रतीक्षा और क्लाइंट को 30 सेकंड का टाइमआउट मिलता है। TASK_ID को सहेजी गई ID पर सेट करें और SOLVETHREE_API_KEY को सर्वर पर रखें। इनमें से कोई भी टाइमआउट बार-बार चलने वाले पोलिंग लूप की कुल समय-सीमा नहीं है।

curl --fail-with-body --max-time 30 \
  "https://api.solvethree.com/v1/tasks/$TASK_ID?waitMs=15000" \
  -H "Authorization: Bearer $SOLVETHREE_API_KEY"

सफल HTTP रिस्पॉन्स में ऐसा टास्क हो सकता है जिसे अब भी पोलिंग चाहिए। pending और solving अंतिम स्थितियाँ नहीं हैं; केवल ready में उपयोग करने योग्य समाधान होता है। failed अंतिम स्थिति है और इसमें errorCode और error शामिल होते हैं।

{
  "nonterminal": [
    {
      "id": "example-task",
      "status": "pending"
    },
    {
      "id": "example-task",
      "status": "solving"
    }
  ],
  "ready": {
    "id": "example-task",
    "status": "ready",
    "solution": {
      "token": "EXAMPLE_TOKEN",
      "userAgent": "EXAMPLE_USER_AGENT",
      "secChUa": "EXAMPLE_CLIENT_HINTS"
    }
  },
  "failed": {
    "id": "example-task",
    "status": "failed",
    "errorCode": "site-unreachable",
    "error": "target page did not respond"
  }
}

यहाँ दिखाए गए तैयार रिस्पॉन्स में reCAPTCHA टोकन है। इसके बजाय Kasada हेडर लौटाता है और TMPT कच्चा कुकी मान लौटाता है। तैयार परिणाम का मतलब है कि समाधान बनाया गया है—यह नहीं कि आगे के लक्ष्य ने उसे स्वीकार कर लिया है। अगर तैयार reCAPTCHA टोकन अस्वीकार हो जाए, तो पोलिंग की समस्या की जाँच छोड़कर भेजे गए टोकन की जाँच करें।

कनेक्शन टाइमआउट बताता है कि क्लाइंट को पूरा रिस्पॉन्स नहीं मिला। इससे यह साबित नहीं होता कि टास्क बनाना विफल हुआ। दूसरे समाधान के लिए भुगतान करने से पहले उस टास्क को रिकवर करें जिसे आप शायद पहले ही बना चुके हैं।

1. 1.

   अगर आपके पास टास्क ID है, तो GET पोलिंग फिर शुरू करें

   नई, सीमित स्थानीय समय-सीमा के साथ उस ID को प्राप्त करें। GET का टाइमआउट होना टास्क बनाने का दूसरा अनुरोध भेजने का कारण नहीं है।

2. 2.

   अगर टास्क बनाना बाधित हुआ था, तो उसके requestId का दोबारा उपयोग करें

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

दोनों SDK, requestId न दिए जाने पर उसे बनाते हैं और टास्क बनाने का प्रयास कभी अपने-आप नहीं दोहराते। उनका SolvethreeError रिकवरी ID उपलब्ध कराता है: Python में request_id और task_id, या JavaScript में requestId और taskId। नया तार्किक टास्क बनाने का निर्णय लेने से पहले इन फ़ील्ड की जाँच करें।

पोलिंग अनुरोध HTTP त्रुटि लौटाता है

HTTP स्टेटस को टास्क की स्थिति से अलग जाँचें। SDK का ApiError वह स्टेटस और दोबारा प्रयास से पहले की प्रतीक्षा उपलब्ध कराता है।

यह आज़माएँ: पोलिंग की अस्थायी विफलताओं के लिए हल करने की कुल समय-सीमा के भीतर Retry-After का पालन करें। SDK फ़ील्ड Python में सेकंड वाला retry_after और JavaScript में मिलीसेकंड वाला retryAfterMs हैं।

टास्क failed लौटाता है

errorCode और error पढ़ें; SDK इसे TaskFailedError के रूप में दर्शाता है।

यह आज़माएँ: उस टास्क की पोलिंग रोक दें। दूसरा टास्क बनाने से पहले बताए गए कारण की जाँच करें; बिना बदलाव किए अमान्य इनपुट का आँख मूँदकर दोबारा प्रयास न करें और न ही मान लें कि समस्या क्रेडिट की है।

प्राप्त करने का अनुरोध HTTP 410 लौटाता है

संग्रहीत परिणाम की अवधि समाप्त हो गई है।

यह आज़माएँ: इसे पोलिंग की अस्थायी त्रुटि मानकर प्राप्त करने का प्रयास दोहराना बंद करें। पूरे हो चुके परिणाम सीमित समय तक रखे जाते हैं और वे स्थायी समाधान कैश नहीं हैं।

तैयार रिस्पॉन्स सहेजने से लक्ष्य के टोकन या कुकी की वैधता अवधि नहीं बढ़ती।