Node.js SDK से स्थानीय प्रतीक्षा रद्द करें

Node.js 22 या उसके बाद के संस्करण पर आधिकारिक JavaScript SDK का उपयोग करें और अपनी API कुंजी सर्वर पर ही रखें। उदाहरण के होस्टनेम और ऐक्शन को अपने लक्ष्य के मानों से बदलें, एक सक्रिय साइट प्रोफ़ाइल कॉन्फ़िगर करें और प्रॉक्सी एनवायरनमेंट वेरिएबल सेट करें।

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

import { randomUUID } from 'node:crypto';
import { Solvethree, SolvethreeError, TaskFailedError } from '@solvethree/sdk';
const client = new Solvethree({ apiKey: process.env.SOLVETHREE_API_KEY });
const task = { site: 'accounts.example.com', action: 'login', proxy: process.env.SOLVETHREE_PROXY, requestId: randomUUID() };
const controller = new AbortController();
const timer = setTimeout(() => controller.abort(), 5000);
try {
  const result = await client.solve(task, { signal: controller.signal, timeoutMs: 180000 });
  console.log('Ready task:', result.id);
  // Submit this result with its browser identity and original proxy.
} catch (error) {
  if (error instanceof TaskFailedError) {
    console.error('Failed task:', error.taskId, error.errorCode);
  } else if (error instanceof SolvethreeError) {
    console.error('Recovery IDs:', error.requestId ?? task.requestId, error.taskId);
    // If taskId exists, retrieve it. Otherwise replay the unchanged task with
    // this requestId. Canceling local waiting did not cancel the remote task.
  }
  throw error;
} finally { clearTimeout(timer); }

पाँच सेकंड का टाइमर abort कॉल करता है; signal उस कंट्रोलर को SDK ऑपरेशन से जोड़ता है। अलग timeoutMs मान समाधान की समय-सीमा 180 सेकंड पर सेट करता है। दोनों में से कोई भी प्रतीक्षा समाप्त कर सकता है, इसलिए दोनों स्थितियों के लिए रिकवरी जानकारी रखें। यदि ऑपरेशन पहले पूरा हो जाता है, तो finally ब्लॉक टाइमर हटा देता है।

catch ब्लॉक रिकवरी ID लॉग करता है और त्रुटि फिर से थ्रो करता है; वह टास्क फिर से जारी नहीं करता। आपके कॉलर को वे ID सुरक्षित रखने और उपयुक्त रिकवरी रास्ता चुनने की ज़रूरत है।

• अंतिम विफलता: उदाहरण की तरह पहले TaskFailedError संभालें। errorCode और त्रुटि संदेश की जाँच करें, फिर उस विफल टास्क की पोलिंग बंद कर दें।
• ज्ञात टास्क ID: यदि SolvethreeError.taskId मौजूद है, तो उसी ID के साथ getTask का उपयोग करके टास्क प्राप्त करना फिर से शुरू करें। केवल पोलिंग फिर से शुरू करने के लिए solve दोबारा कॉल न करें।
• टास्क ID उपलब्ध नहीं: सहेजे गए, अपरिवर्तित टास्क को उसी requestId के साथ createTask में देकर टास्क निर्माण को रिकवर करें। उपलब्ध होने पर त्रुटि के requestId का उपयोग करें, अन्यथा कॉल से पहले सहेजे गए ID का उपयोग करें। कनेक्शन बाधित होना यह साबित नहीं करता कि टास्क बनाना विफल रहा।

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

टास्क प्राप्त करते समय, pending और solving का मतलब है कि अपनी चुनी हुई स्थानीय सीमा के भीतर प्रतीक्षा करते रहें। केवल ready में उपयोग करने योग्य समाधान होता है। failed पर रुकें और उसकी त्रुटि के विवरण की जाँच करें।

1. 1.

   एक परीक्षण अनुरोध सहेजें

   उदाहरण चलाने से पहले पूरा टास्क इनपुट और उसका requestId दर्ज करें। पूरे परीक्षण के दौरान ये मान सुरक्षित रखें।

2. 2.

   देखें कि पहली कॉल कैसे समाप्त होती है

   यदि पाँच सेकंड का टाइमर चलने पर ऑपरेशन अभी भी प्रतीक्षा कर रहा है, तो उससे मिली त्रुटि और रिकवरी ID दर्ज करें। तैयार परिणाम या अंतिम विफलता पहले भी आ सकती है; ऐसे रन में रद्दीकरण का परीक्षण नहीं हुआ है।

3. 3.

   उसी टास्क को फिर से जारी करें

   टास्क ID पाने के लिए ऊपर दिया गया रिकवरी रास्ता अपनाएँ, फिर उस ID के साथ getTask कॉल करें और waitMs को 15000 पर सेट करें। प्राप्त करने के प्रयासों की संख्या सीमित करें या परीक्षण की स्थानीय समय-सीमा तय करें। यदि सीमा पूरी होने पर टास्क pending या solving ही रहता है, तो दूसरा टास्क बनाने के बजाय बाद में जारी करने के लिए उसका ID सुरक्षित रखें।

जब भी मूल टास्क ID पहले से ज्ञात हो, जाँचें कि रिकवरी वही ID लौटाती है। इससे स्थानीय रद्दीकरण और टास्क रिकवरी की जाँच होती है—इसकी नहीं कि लक्ष्य वेबसाइट परिणामस्वरूप मिले टोकन को स्वीकार करती है या नहीं।