CAPTCHA görevlerinin düzenli sorgulanmasını ve zaman aşımlarını yönetin

waitMs, bir API isteğinin yanıt vermeden önce sonuç için ne kadar bekleyeceğini belirler. Görev JSON’undaki bir alan değil, URL sorgu parametresidir. Oluşturma varsayılanları ürüne göre değişir; GET sorgulamasının ayrı bir sınırı vardır.

HTTP istemcisine, istenen sunucu beklemesine ek olarak ağ gecikmelerini de karşılayacak kadar süre tanıyın. Sunucu beklemesinden kısa bir istemci zaman aşımı, görevin güncel durumunu almadan yanıtın kesilmesine yol açabilir.

Resmî SDK’ların solve metodu, görevi bir kez oluşturur ve hazır bir sonuç veya hata alınana kadar sorgular. Python, saniye cinsinden timeout ve poll_interval sunar; Node.js ise milisaniye cinsinden timeoutMs ve pollIntervalMs sunar. Belgelenen ayarlar, üç dakikalık çözüm süresi sınırı ve bir saniyelik sorgulama aralığı kullanır.

Doğrudan kontrol için Python create_task ve get_task, Node.js ise createTask ve getTask sağlar. Şu sırayı izleyin:

1. 1.

   Bir süre sınırı belirleyin ve tek bir görev oluşturun

   Oluşturmadan önce genel bir süre sınırı belirleyin. Kesintiye uğrayan oluşturma işleminin kurtarılabilmesi için bir requestId değerini görev girdilerinin aynısıyla birlikte saklayın. Oluşturma sırasında beklememek için bekleme süresini açıkça sıfır olarak seçin.

2. 2.

   Döndürülen görev kimliğini kaydedin ve durumunu inceleyin

   Oluşturma işlemi zaten nihai bir sonuç döndürebilir. Durum ready olduğunda çözümü döndürün. Durum failed olduğunda errorCode ve error alanlarını inceleyip durun; başarısız çözümlerin ücreti iade edilir. Yalnızca pending ve solving durumları ek sorgulama gerektirir.

3. 3.

   Süre kaldığı sürece aynı görevi alın

   İsteğe bağlı olarak en fazla 15000 ms uzun sorgulama beklemesiyle GET /v1/tasks/:id kullanın. Başarı yanıtının içeriğini okumadan önce başarısız HTTP yanıtlarını ele alın. Yanıt hâlâ pending veya solving durumunu bildiriyorsa, başka bir görev oluşturarak değil, aynı kimlikle tekrarlayın.

4. 4.

   Süre sınırında durun

   Ağ gecikmelerini hesaba katarak her isteği kalan süreyle sınırlayın. Süre sınırınız dolduğunda yerel döngüyü durdurun ve kurtarma için görev kimliğini saklayın. Sırf istemciniz beklemeyi bıraktı diye görevi başarısız olarak yeniden etiketlemeyin.

Bu istek, 15 saniyelik sunucu beklemesine ve 30 saniyelik istemci zaman aşımına izin vererek mevcut bir görevi alır. TASK_ID değerini kaydedilen kimliğe ayarlayın ve SOLVETHREE_API_KEY değerini sunucuda tutun. Bu zaman aşımlarının hiçbiri, tekrarlanan bir sorgulama döngüsü için genel süre sınırı değildir.

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

Başarılı bir HTTP yanıtı, hâlâ sorgulanması gereken bir görev içerebilir. pending ve solving nihai durumlar değildir; yalnızca ready kullanılabilir bir çözüm içerir. failed nihai bir durumdur ve errorCode ile error içerir.

{
  "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"
  }
}

Burada gösterilen hazır yanıt bir reCAPTCHA belirteci içerir. Kasada bunun yerine başlıklar, TMPT ise ham bir çerez değeri döndürür. Hazır bir sonuç, çözümün oluşturulduğu anlamına gelir; sonraki hedefin bunu kabul ettiği anlamına gelmez. Hazır bir reCAPTCHA belirteci reddedilirse, sorgulama tanılamasından gönderilen belirteci kontrol etmeye geçin.

Bağlantı zaman aşımı, istemcinin tam bir yanıt almadığını gösterir. Oluşturma işleminin başarısız olduğunu kanıtlamaz. Başka bir çözüm için ödeme yapmadan önce, zaten oluşturmuş olabileceğiniz görevi kurtarın.

1. 1.

   Görev kimliğiniz varsa GET sorgulamasına devam edin

   Yeni ve sınırlı bir yerel süre sınırıyla bu kimliğe ait görevi alın. Zaman aşımına uğrayan bir GET, başka bir oluşturma isteği göndermek için gerekçe değildir.

2. 2.

   Oluşturma kesintiye uğradıysa aynı requestId değerini yeniden kullanın

   Mevcut görevi kurtarmak için aynı görev isteğini aynı requestId ile yeniden gönderin. Bu kimliği yeniden kullanırken görev girdilerini değiştirmek çakışmaya yol açar. Tüm kurallar için istek kimliğiyle kurtarma kılavuzuna bakın.

Her iki SDK da belirtilmediğinde bir requestId oluşturur ve oluşturma işlemini hiçbir zaman otomatik olarak yeniden denemez. SolvethreeError, kurtarma kimliklerini sunar: Python’da request_id ve task_id, JavaScript’te ise requestId ve taskId. Yeni bir mantıksal görev oluşturmaya karar vermeden önce bu alanları kontrol edin.

Sorgulama isteği HTTP hatası döndürüyor

HTTP durumunu görev durumundan ayrı inceleyin. SDK’nın ApiError hatası, bu durumu ve varsa yeniden deneme gecikmesini sunar.

Şunu deneyin: Geçici sorgulama hatalarında, genel çözüm süresi sınırı içinde Retry-After değerine uyun. SDK alanları, Python’da saniye cinsinden retry_after ve JavaScript’te milisaniye cinsinden retryAfterMs şeklindedir.

Görev failed durumunu döndürüyor

errorCode ve error alanlarını okuyun; SDK bunu TaskFailedError olarak temsil eder.

Şunu deneyin: Bu görevi sorgulamayı durdurun. Başka bir görev oluşturmadan önce bildirilen nedeni tanılayın; geçersiz girdileri değiştirmeden körü körüne yeniden denemeyin veya sorunun bakiye olduğunu varsaymayın.

Alma işlemi HTTP 410 döndürüyor

Saklanan sonucun süresi dolmuş.

Şunu deneyin: Bu durumu geçici bir sorgulama hatası gibi ele alıp alma işlemini yeniden denemeyi bırakın. Tamamlanan sonuçların saklama süresi sınırlıdır ve bunlar kalıcı bir çözüm önbelleği değildir.

Hazır bir yanıtı kaydetmek, hedefin belirteç veya çerez ömrünü uzatmaz.