asyncio से सिंक्रोनस Python SDK का उपयोग करें

उदाहरण के लिए Python 3.10+ और आधिकारिक Python SDK आवश्यक हैं। अपने सर्वर एनवायरनमेंट में SOLVETHREE_API_KEY और SOLVETHREE_PROXY सेट करें। accounts.example.com और login की जगह अपना लक्ष्य होस्टनाम और ऐक्शन डालें। साइट के लिए आपके वर्कस्पेस में पहले से एक सक्रिय प्रोफ़ाइल उपलब्ध होनी चाहिए; साइट प्रोफ़ाइल सेटअप देखें।

import asyncio
import os
import uuid
from solvethree import Solvethree

async def main():
    limit = asyncio.Semaphore(4)
    async def solve_one(number):
        task = {"site": "accounts.example.com", "action": "login", "proxy": os.environ["SOLVETHREE_PROXY"], "requestId": str(uuid.uuid4())}
        def blocking_solve():
            return Solvethree(os.environ["SOLVETHREE_API_KEY"]).solve(task, timeout=180)
        async with limit:
            try:
                result = await asyncio.to_thread(blocking_solve)
                print("Ready task:", result["id"])
                # Submit the solution now with its proxy and browser identity.
            except Exception as error:
                print("Job", number, "requestId", task["requestId"], "error class", type(error).__name__)
                # Retain task and inspect SDK recovery IDs before restarting it.
    await asyncio.gather(*(solve_one(number) for number in range(8)))

asyncio.run(main())
# Canceling an await does not stop an already-running thread or remote task.

• सेमाफोर gather को सबमिट किए गए आठ जॉब में से एक बार में चार को प्रवेश देता है। स्लॉट की प्रतीक्षा कर रहे जॉब ने अपनी SDK कॉल शुरू नहीं की होती।
• हर वर्कर थ्रेड के बीच एक क्लाइंट साझा करने के बजाय अपना अलग Solvethree क्लाइंट बनाता है।
• SDK का timeout=180 सॉल्व की समय-सीमा तय करता है। सेमाफोर की प्रतीक्षा में लगा समय इसमें शामिल नहीं है। await के आसपास लगाया गया asyncio टाइमआउट इस SDK समय-सीमा का विकल्प नहीं है।
• टास्क और उसका requestId वर्कर में प्रवेश करने से पहले बनाए जाते हैं। हर त्रुटि पर नई ID बनाने के बजाय, रिकवरी के लिए दोनों को उपलब्ध रखें।

SDK टास्क एक बार बनाता है और उसके तैयार होने या त्रुटि उठने तक पोल करता है। आपको solve के आसपास दूसरा पोलिंग लूप लिखने की ज़रूरत नहीं है।

to_thread की प्रतीक्षा कर रही कोरूटीन को रद्द करने से पहले से चल रहा थ्रेड नहीं रुकता और न ही रिमोट सॉल्व रद्द होता है। नमूने का सामान्य एक्सेप्शन हैंडलर कैंसलेशन क्लीनअप नहीं है।

इसका असर समवर्तिता सीमा पर भी पड़ता है: कैंसलेशन से सेमाफोर रिलीज़ हो सकता है, जबकि वर्कर चलता रहता है। यदि आप तुरंत उनकी जगह नए जॉब को प्रवेश देते हैं, तो चार से अधिक SDK कॉल सक्रिय रह सकती हैं। कैंसलेशन के दौरान भी सख्त सीमा चाहिए, तो अधूरे वर्कर ट्रैक करें और उनके पूरा होने तक उनकी क्षमता आरक्षित रखें।

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

1. 1.

   ज्ञात टास्क रिकवर करें

   Python SDK की त्रुटि में task_id और request_id जाँचें। यदि आपके पास टास्क ID है, तो दूसरा टास्क बनाने के बजाय get_task से परिणाम प्राप्त करना फिर शुरू करें।

2. 2.

   बीच में रुके निर्माण को रिकवर करें

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

3. 3.

   विफलता और व्यवधान में अंतर करें

   TaskFailedError का अर्थ है कि टास्क अंतिम विफल स्थिति तक पहुँच गया है। इसके errorCode और error जाँचें; इसकी पोलिंग जारी न रखें और न ही बिना बदले अमान्य इनपुट पर आँख मूँदकर दोबारा प्रयास करें। HTTP त्रुटियाँ विफलता की एक अलग परत हैं।

नमूना तैयार टास्क की ID प्रिंट करता है; यह लक्ष्य को कुछ सबमिट नहीं करता। उस प्रिंट के बाद के कमेंट की जगह अपने एप्लिकेशन का सबमिशन कोड डालें, और gather के हर जॉब के पूरा होने की प्रतीक्षा करने के बजाय समाधान का तुरंत उपयोग करें।

लौटाया गया समाधान उसके userAgent, secChUa और सॉल्व करने में उपयोग की गई उसी प्रॉक्सी के साथ सबमिट करें। SDK का successful_proxy हेल्पर मूल टास्क और तैयार परिणाम से प्रॉक्सी चुनता है। तैयार परिणाम का अर्थ है कि समाधान जनरेट हुआ—यह नहीं कि आपका एप्लिकेशन अनुरोध सफल हुआ।