حدود الطلبات المتزامنة في CaptchaAI: تشخيص ERROR_NO_SLOT_AVAILABLE وإصلاحه

كل خطة في CaptchaAI تمنحك عدداً محدّداً من الـ threads، وكل thread يعالج طلب CAPTCHA واحداً في اللحظة نفسها. حين تمتلئ كل الـ threads وتحاول إرسال مهمة إضافية، تُرجع الخدمة الخطأ ERROR_NO_SLOT_AVAILABLE. الرسالة ليست عطلاً في حسابك، بل إشارة إلى أنك بلغت سقف التزامن المتاح في اشتراكك. نفكّك في هذا الدليل سبب الخطأ، ونميّزه عن رمز HTTP 429، ونستعرض خمس طرق عملية للتحكم بالتزامن ورفع الإنتاجية دون الاصطدام بالسقف.

لماذا تظهر رسالة ERROR_NO_SLOT_AVAILABLE؟

تفوتر CaptchaAI حسب عدد الـ threads المتزامنة، لا حسب عدد عمليات الحل. يتلخّص الأمر في ثلاث نقاط:

• الـ thread الواحد خانة معالجة تحتجز طلب CAPTCHA واحداً حتى يكتمل حلّه، ثم تتحرّر لتستقبل الطلب التالي.
• ما دام عدد مهامك النشطة أقل من عدد الـ threads في خطتك، يمضي كل شيء بسلاسة.
• عند تجاوز هذا العدد، لا تجد الطلبات الزائدة خانة فارغة، فترجع فوراً بالخطأ ERROR_NO_SLOT_AVAILABLE.

الخلاصة أن العلاج ليس في إرسال طلبات أكثر بسرعة أكبر، بل في مطابقة إيقاع الإرسال لعدد الـ threads المتاح لك. المشكلة تتضح غالباً عند الذروة، حين يُطلق سكربت الأتمتة دفعة كبيرة من الطلبات دفعة واحدة تفوق سعة حسابك المتزامنة.

الأعراض وكيف تميّزها

قبل أي إصلاح، اعرف أي حدٍّ اصطدمت به بالضبط:

القاعدة العملية بسيطة: ERROR_NO_SLOT_AVAILABLE مشكلة تزامن (عدد مهام متوازية أكثر من اللازم)، بينما HTTP 429 مشكلة معدّل (طلبات في الثانية أكثر من اللازم)، ولكلٍّ منهما علاج مختلف تماماً.

نوعا الحدود في CaptchaAI

يعمل في CaptchaAI حاجزان مستقلان، ومن المفيد التمييز بينهما بوضوح:

• المهام المتزامنة — تتحكّم بأقصى عدد من المهام قيد الحل في اللحظة نفسها، ومرتبطة مباشرة بعدد الـ threads في خطتك. تجاوزها يعطي ERROR_NO_SLOT_AVAILABLE.
• معدّل الطلبات — يتحكّم بأقصى عدد لاستدعاءات API في الثانية إلى نقطتَي الإرسال والاستطلاع، ويُستنزف بسهولة عند الاستطلاع المتكرر. تجاوزه يعطي HTTP 429.

تحقّق من حدّك الحالي من لوحة التحكم على captchaai.com، فهو نقطة البداية لأي ضبط لاحق.

كيف يحدّد اشتراكك عدد المهام المتزامنة

بما أن كل thread يعادل خانة معالجة واحدة، فإن عدد الـ threads في خطتك هو نفسه أقصى عدد من المهام المتزامنة التي يمكنك تشغيلها. جميع الخطط تشمل عدداً غير محدود من عمليات الحل لكل thread خلال الشهر، فلا رسوم لكل CAPTCHA ولا سقوف يومية؛ القيد الوحيد هو عدد الخانات المتوازية:

خذ مثالاً واقعياً: فريق يراقب أسعار متاجر إلكترونية في منطقة الخليج قد يشغّل نحو 40 مهمة reCAPTCHA v2 بالتوازي في ساعة الذروة. خطة BASIC بخمسة threads سترجع ERROR_NO_SLOT_AVAILABLE فور تجاوز الخانات الخمس، بينما تستوعب خطة ADVANCE (50 thread مقابل 90 دولاراً شهرياً) هذا الحمل مع هامش أمان. القاعدة أن تفكّر في عدد الـ threads بدلالة أعلى تزامن فعلي تحتاجه، لا بدلالة إجمالي الطلبات اليومية.

الإصلاح 1: تحديد التزامن عبر إشارة Semaphore

أبسط ضبط للتزامن هو تقييد عدد المهام الجارية في اللحظة نفسها عبر Semaphore. اجعل MAX_CONCURRENT أقل قليلاً من عدد الـ threads في خطتك لتترك مجالاً لإعادة المحاولة، ثم غلّف كل عملية حل داخل الإشارة كي لا يتجاوز عدد الطلبات النشطة الحدّ أبداً:

import requests
import time
import threading

API_KEY = "YOUR_API_KEY"
MAX_CONCURRENT = 20  # Stay below your account limit

semaphore = threading.Semaphore(MAX_CONCURRENT)


def solve_captcha(params):
    """Solve a CAPTCHA with concurrency control."""
    with semaphore:
        params["key"] = API_KEY
        params["json"] = 1

        submit = requests.post("https://ocr.captchaai.com/in.php", data=params).json()
        if submit.get("status") != 1:
            raise RuntimeError(f"Submit: {submit.get('request')}")

        task_id = submit["request"]
        time.sleep(10)

        for _ in range(30):
            result = requests.get("https://ocr.captchaai.com/res.php", params={
                "key": API_KEY, "action": "get", "id": task_id, "json": 1
            }).json()
            if result.get("status") == 1:
                return result["request"]
            if result.get("request") != "CAPCHA_NOT_READY":
                raise RuntimeError(f"Solve: {result['request']}")
            time.sleep(5)
        raise TimeoutError("Timed out")

الإصلاح 2: أعد المحاولة عند ERROR_NO_SLOT_AVAILABLE

حتى مع وجود Semaphore، قد تلامس السقف حين تتشارك عدة عمليات الحساب نفسه. بدل أن يفشل الطلب فوراً، انتظر ثم أعد الإرسال وفق تراجع أسّي يضاعف زمن الانتظار في كل محاولة (ثانية، ثم اثنتان، ثم أربع...)، ما يمنح الـ threads وقتاً كي تتحرّر:

def submit_with_retry(params, max_retries=5):
    """Submit with automatic retry for slot errors."""
    params["key"] = API_KEY
    params["json"] = 1

    for attempt in range(max_retries):
        resp = requests.post("https://ocr.captchaai.com/in.php", data=params).json()

        if resp.get("status") == 1:
            return resp["request"]

        error = resp.get("request", "")
        if error == "ERROR_NO_SLOT_AVAILABLE":
            wait = 2 ** attempt  # Exponential backoff: 1, 2, 4, 8, 16 seconds
            print(f"No slot available, retrying in {wait}s (attempt {attempt + 1})")
            time.sleep(wait)
            continue
        else:
            raise RuntimeError(f"Submit error: {error}")

    raise RuntimeError("Max retries exceeded — no slots available")

الإصلاح 3: نظّم العمل عبر قائمة انتظار

بدل إغراق واجهة البرمجة بدفعة واحدة، ادفع المهام إلى قائمة انتظار ومرّرها على عدد ثابت من العمّال (workers) يساوي حدّ التزامن. بهذا تعالج آلاف المهام بمعدل ثابت ومضبوط بدل موجة مفاجئة تستنزف الـ threads دفعة واحدة:

from queue import Queue
from threading import Thread

task_queue = Queue()
results = {}


def worker():
    while True:
        task_id_local, params = task_queue.get()
        try:
            token = solve_captcha(params)
            results[task_id_local] = {"status": "ok", "token": token}
        except Exception as e:
            results[task_id_local] = {"status": "error", "message": str(e)}
        finally:
            task_queue.task_done()


# Start worker threads (limited by semaphore)
for _ in range(MAX_CONCURRENT):
    t = Thread(target=worker, daemon=True)
    t.start()

# Add tasks to queue
captcha_tasks = [
    {"method": "userrecaptcha", "googlekey": "KEY1", "pageurl": "https://site1.com"},
    {"method": "userrecaptcha", "googlekey": "KEY2", "pageurl": "https://site2.com"},
    # ... more tasks
]

for i, params in enumerate(captcha_tasks):
    task_queue.put((i, params))

task_queue.join()
print(f"Completed: {len(results)} tasks")

الإصلاح 4: اضبط وتيرة استطلاع النتيجة

الاستطلاع الدوري كل ثانية يهدر استدعاءات API ويقود سريعاً إلى رمز HTTP 429. القاعدة الصحيحة تتلخّص في ثلاث درجات:

• خطأ شائع: استطلاع النتيجة كل ثانية واحدة.
• الصواب: استطلاع كل 5 ثوانٍ بدل كل ثانية.
• الأفضل: مهلة أولية 10–15 ثانية قبل أول استطلاع، ثم كل 5 ثوانٍ.

# WRONG — polling every 1 second
time.sleep(1)

# CORRECT — poll every 5 seconds
time.sleep(5)

# BETTER — wait longer on initial delay, then poll
time.sleep(15)  # Initial wait
for _ in range(20):
    # ... poll
    time.sleep(5)

راقب المهام النشطة لحظياً

لتعرف قربك من السقف قبل بلوغه، احتفظ بعدّاد للمهام النشطة واطبعه مع كل عملية. يكشف هذا الأنماط بوضوح: إذا لامست باستمرار قيمة MAX_CONCURRENT، فأنت بحاجة إلى threads أكثر لا إلى إعادة محاولة أكثر:

active_count = 0
lock = threading.Lock()

def track_solve(params):
    global active_count
    with lock:
        active_count += 1
        print(f"Active tasks: {active_count}/{MAX_CONCURRENT}")
    try:
        return solve_captcha(params)
    finally:
        with lock:
            active_count -= 1

الأسئلة الشائعة

كم عدد المهام المتزامنة الذي تسمح به خطتي؟

يساوي عدد الـ threads في اشتراكك: 5 في خطة BASIC، و15 في STANDARD، و50 في ADVANCE، وصولاً إلى 5,000 في VIP-3. راجع لوحة التحكم لمعرفة حدّك الحالي، وارفعه بالانتقال إلى خطة أعلى.

هل يخصم خطأ ERROR_NO_SLOT_AVAILABLE من رصيدي؟

لا. التسعير في CaptchaAI قائم على عدد الـ threads لا على كل طلب، وعمليات الحل غير محدودة لكل thread. الطلب المرفوض بسبب امتلاء الخانات لا يُحتسب حلاً ولا يستهلك رصيداً، لذا إعادة المحاولة الآمنة لا تكلّفك شيئاً إضافياً.

ما الفرق بين ERROR_NO_SLOT_AVAILABLE ورمز HTTP 429؟

الأول يعني أن عدد المهام قيد الحل بلغ سقف الـ threads لديك، وعلاجه تقليل التزامن أو رفع الخطة. أما HTTP 429 فيعني أن عدد استدعاءاتك في الثانية مرتفع جداً — حتى استطلاع النتيجة يُحتسب — وعلاجه إبطاء وتيرة الطلبات. كلاهما يتطلّب التراجع، لكن على محورين مختلفين.

هل زيادة عدد الـ threads تُسرّع حل كل CAPTCHA؟

لا مباشرة. مزيد من الـ threads يعني معالجة مهام أكثر بالتوازي، أي إنتاجية أعلى، لكن زمن حل الـ CAPTCHA الواحد يبقى محكوماً بنوعه وبسرعة الخدمة. إن كان همّك بطء مهمة مفردة فراجع خفض زمن استجابة واجهة CaptchaAI API بدل رفع عدد الـ threads.

متى ألجأ إلى قائمة الانتظار بدل رفع الخطة؟

استخدم قائمة الانتظار حين يكون حِملك متفاوتاً: دفعات مفاجئة يفصل بينها هدوء، فهي تنعّم الذروة ضمن الـ threads المتاحة. أما إذا بقي التزامن الفعلي أعلى من خطتك على مدار اليوم، فرفع الخطة هو الحل الأصح، إذ لا تُجدي القائمة نفعاً حين يكون الطلب المستمر أكبر من السعة.

وسّع طاقة الحل في CaptchaAI

رفع الإنتاجية يبدأ من مطابقة عدد الـ threads لحجم عملك الفعلي. راجع خطتك على captchaai.com وشغّل مهامك المتوازية بثبات ودون أخطاء تزامن.

أدلة ذات صلة

• أنماط معالجة أخطاء رد النداء (callback) في CaptchaAI
• خفض زمن استجابة واجهة CaptchaAI API