Başka bir görev için ödeme yapmadan zaman aşımına uğrayan isteği kurtarın

Bir requestId, oluşturma denemeleri boyunca tek bir mantıksal görevi tanımlar. 1–64 ASCII harfi, rakam, alt çizgi veya kısa çizgi kabul eder. İsteği göndermeden önce belirleyin ve özgün görev girdileriyle birlikte saklayın.

1. 1.

   Görev gövdesini kaydedin

   requestId dahil isteğin tamamını request.json dosyasına koyun. reCAPTCHA Enterprise için ana makine adı olarak site, action ve proxy veya proxyCandidates alanlarından tam olarak birini ekleyin. type veya url eklemeyin. Proxy kimlik bilgileri içerdiğinden dosyayı gizli tutun.

2. 2.

   Kaydedilen dosyayı gönderin

   Aşağıdaki komutu çalışma alanınızın API anahtarıyla çalıştırın. Anahtarı sunucuda tutun.

3. 3.

   Bağlantı zaman aşımına uğrarsa komutu tekrarlayın

   Tam olarak aynı komutu ve değiştirilmemiş request.json dosyasını kullanın. Sırf yanıt gelmedi diye başka bir requestId oluşturmayın veya görev girdilerini düzenlemeyin.

# request.json contains one valid task body and a saved requestId.
# Keep the file private: it contains your proxy credentials.
curl --fail-with-body --max-time 30 \
  'https://api.solvethree.com/v1/tasks?waitMs=0' \
  -H "Authorization: Bearer $SOLVETHREE_API_KEY" \
  -H 'Content-Type: application/json' --data-binary @request.json

# If the connection broke, run the identical command with the identical file.
# New task: HTTP 201. Same requestId + same inputs: HTTP 200, existing task.
# Same requestId + changed inputs: HTTP 409.

HTTP 201, yeni bir görev oluşturulduğu anlamına gelir. HTTP 200, aynı isteğin mevcut görevi kurtardığı anlamına gelir. Her iki durumda da döndürülen görev kimliğini ve durumunu okuyun; bu HTTP durumlarının hiçbiri tek başına çözümün hazır olduğu anlamına gelmez.

Değişen girdilere somut bir örnek olarak, kaydedilen istekte action değerinin login olduğunu varsayalım. Aynı requestId korunurken bu değerin checkout olarak değiştirilmesi, istek kimliği çakışması olan HTTP 409 yanıtını döndürür. Özgün görevi kurtarmak için özgün dosyayı geri yükleyip yeniden gönderin. Değiştirilmiş girdilere bilinçli olarak ihtiyacınız varsa bu yeni mantıksal göreve yeni bir requestId verin.

Başarılı görev yanıtının içeriğini okumadan önce başarısız HTTP yanıtlarını işleyin. 409, bir HTTP istek hatasıdır; özgün görevin nihai olarak başarısız olması değildir.

Her iki resmî SDK da belirtmediğinizde bir requestId oluşturur, ancak hiçbiri görev oluşturmayı otomatik olarak yeniden denemez. Bir SDK çağrısı hata fırlatırsa başka bir görev başlatmadan önce kurtarma alanlarını inceleyin.

• JavaScript: SolvethreeError, requestId ve taskId alanlarını sunar.
• Python: SolvethreeError, request_id ve task_id alanlarını sunar.

Hata bir görev kimliği içeriyorsa o görev için GET ile durum sorgulamaya devam edin; oluşturmayı tekrarlamanız gerekmez. Yalnızca istek kimliği içeriyorsa bu kimlik ve özgün girdilerle oluşturma isteğini yeniden gönderin, ardından döndürülen görev kimliğini kullanın. Kimliği SDK oluşturmuş olsa bile özgün girdileri saklamak önemlidir.

Her istisnayı kesintiye uğramış bir oluşturma işlemi olarak değerlendirmeyin. TaskFailedError, kurtarılması gereken bir isteği değil, zaten nihai başarısız duruma ulaşmış bir görevi temsil eder.

Kurtarılan görevi GET /v1/tasks/:id ile alın. Durumu pending veya solving olduğu sürece sorgulamaya devam edin. Yalnızca ready, kullanılabilir bir çözüm içerir.

Durum failed ise sorgulamayı durdurun ve errorCode ile error alanlarını inceleyin. Başarısız çözüm işlemlerinin ücreti iade edilir. Bu, bir web sitesinin üretilen çözümü reddetmesinden farklıdır: ready, çözümün kullanılabilir olduğu anlamına gelir, hedefin bunu kabul ettiği anlamına gelmez.

Tamamlanan sonuçlar, saklama süresi dolduktan sonra HTTP 410 döndürebilir; dolayısıyla kurtarma, sonuçların kalıcı olarak saklanması anlamına gelmez. Sorgulama döngüsünün kendisi için görev sorgulama ve zaman aşımları bölümüne bakın.