task_id, and let the worker die and
come back without losing anything. This recipe is the wiring that makes that safe.
1. Check credits before a batch
A worker that starts fifty tasks against an empty balance produces fifty402s. Check
once per batch, not per task:
2. Start the task, then persist the id first
Thetask_id is your resume point. Write it to your database before doing anything
else with the response. If the worker crashes one line later, the task is still running in
the cloud and the stored id is how you find it again.
/task/start instead. See The task model.
3. Poll with the full terminal check
Workers are exactly where a sloppy exit condition hurts most, because nobody is watching the loop spin. Use the complete check from Task lifecycle, including thedeleted and out_of_credits cases, and poll on a lazy interval; a research task does
not need sub-second updates.
4. Serialize writes per task
A task runs one turn at a time, so two workers continuing the sametask_id produce a
409, not a queue. Route all writes for one task through one worker (or take a per-task
lock), and treat 409 as “try again after the current turn”, never as a failure. See
Errors.
5. Land the rows
Fetch the rows, flatten the cells into your own schema, and keep_sources if anything
downstream needs to audit a value:
Crash recovery
On restart, reread the stored ids and resume polling; the tasks never stopped. If you lose the ids entirely,GET /task lists recent tasks so you can reconcile against your queue.
Related
Task lifecycle
The terminal check this worker depends on.
Follow-up tasks
Sending refinements to a task the worker already finished.