Recupere uma requisição que excedeu o tempo limite sem pagar por outra tarefa

Um requestId identifica uma única tarefa lógica entre as tentativas de criação. Ele aceita de 1–64 letras ASCII, números, sublinhados ou hífens. Escolha-o antes de enviar a requisição e mantenha-o junto dos dados de entrada originais da tarefa.

1. 1.

   Salve o corpo da tarefa

   Coloque a requisição completa, incluindo requestId, em request.json. Para reCAPTCHA Enterprise, inclua site como um nome de host, action e exatamente um dos campos proxy ou proxyCandidates. Não adicione type nem url. Mantenha o arquivo privado, pois ele contém credenciais de proxy.

2. 2.

   Envie o arquivo salvo

   Execute o comando abaixo com a chave de API do seu espaço de trabalho. Mantenha a chave no servidor.

3. 3.

   Se a conexão atingir o tempo limite, repita o comando

   Use o mesmo comando e o arquivo request.json sem alterações. Não gere outro requestId nem edite os dados de entrada da tarefa só porque a resposta não chegou.

# 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 significa que uma nova tarefa foi criada. HTTP 200 significa que a requisição idêntica recuperou a tarefa existente. Leia o ID e o status da tarefa retornados em ambos os casos; nenhum desses status HTTP, por si só, significa que uma solução está pronta.

Como exemplo concreto de alteração dos dados de entrada, suponha que a requisição salva tenha action definido como login. Alterá-lo para checkout mantendo o mesmo requestId retorna HTTP 409, um conflito de ID de requisição. Para recuperar a tarefa original, restaure o arquivo original e reenvie-o. Se você realmente precisar dos dados alterados, atribua um novo requestId a essa nova tarefa lógica.

Trate as respostas HTTP sem sucesso antes de ler um payload de sucesso da tarefa. Um 409 é um erro de requisição HTTP, não uma falha terminal da tarefa original.

Ambos os SDKs oficiais geram um requestId quando você o omite, mas nenhum deles repete automaticamente a criação da tarefa. Se uma chamada do SDK lançar uma exceção, verifique seus campos de recuperação antes de iniciar outra tarefa.

• JavaScript: SolvethreeError expõe requestId e taskId.
• Python: SolvethreeError expõe request_id e task_id.

Se o erro contiver um ID de tarefa, retome as consultas GET periódicas dessa tarefa; não é necessário repetir a criação. Se contiver apenas um ID de requisição, reenvie a criação com esse ID e os dados de entrada originais e, em seguida, use o ID de tarefa retornado. Preservar os dados de entrada originais é importante mesmo quando o SDK gerou o ID.

Não trate toda exceção como uma criação interrompida. TaskFailedError representa uma tarefa que já atingiu o estado terminal de falha, não uma requisição que precisa de recuperação.

Consulte a tarefa recuperada com GET /v1/tasks/:id. Continue consultando periodicamente enquanto o status for pending ou solving. Somente ready contém uma solução utilizável.

Se o status for failed, pare de consultar e verifique errorCode e error. Resoluções que falham são reembolsadas. Isso é diferente de um site rejeitar uma solução gerada: ready significa que a solução está disponível, não que o destino a aceitou.

Resultados concluídos podem retornar HTTP 410 após o prazo de retenção expirar, portanto a recuperação não é um armazenamento permanente de resultados. Para o próprio loop de consultas, consulte consultas periódicas de tarefas e tempos limite.