jobs_result with job_ids: read ok per entry, re-read failed_job_ids

Sume's remote MCP jobs_result accepts job_ids (1 to 20 ids) and returns a job_result_batch: one entry per id, in request order, each with ok plus either value or a typed error. A job that is still running comes back as job_not_completed for that entry only, while every finished id still returns its result.

So the rule for callers is to read ok on each entry and to re-read only the ids listed in partial_failure.failed_job_ids. A failure on one id says nothing about the others.

What does a batch jobs_result response look like?

You send the same ids you waited on. The request shape from the Jobs and results page is just a list:

• results[] is in request order, one entry per id, so you can zip it back to your own list.
• Each entry has ok. When ok is true there is a value; when it is false there is a typed error.
• partial_failure.failed_job_ids names exactly the ids worth re-reading.

{ "job_ids": ["job_a", "job_b", "job_c"] }

Why does one id come back as job_not_completed?

Results exist only after completion. For a single job over the HTTP API, asking early returns 409 job_not_completed instead of an empty result. In a batch the same condition is reported per entry, so the response itself stays a success and the entry carries the typed error.

That is deliberate. The docs call partial success normal: a wave of ten jobs rarely finishes at the same instant, and failing the whole read because job seven is still processing would force you to call again for the nine that were ready.

How do I loop over a wave without losing results?

Keep a map from job id to its result. After each batch read, store every entry with ok: true, then take partial_failure.failed_job_ids as the next list to read. Do not resubmit anything: a job_not_completed entry means the job exists and is on its way, not that it was lost.

Between reads, use jobs_wait on just the missing ids rather than reading in a tight loop. A wait returns the moment its jobs are terminal, and remote MCP holds each call to at most 55 seconds (default 50), so repeat the wait with the same ids if you get wait_slice_expired.

Not every entry error is a pending job. A failed job returns a typed error too, and that one will not fix itself by re-reading. Look at the error code on the entry before deciding it belongs in a retry list: job_not_completed is worth re-reading after a wait, while a failure on the job itself needs the error read off the job record.

What can I not do with this?

The batch ceiling is 20 ids, the same as jobs_wait, so a larger fan-out needs several calls. The docs do not describe a way to read results for ids from a different workspace in the same call; unknown or foreign-workspace ids fail a whole jobs_wait call, so keep each batch to ids you created in the workspace your key or session is connected to.

If you want results to arrive with the wait instead of in a second call, the wait itself has an include_results option that returns each completed id's jobs_result answer in results[]. Results that do not fit in one answer are named in results_omitted.job_ids, and you read those with one batch jobs_result.

Keep your own record of which ids you submitted in each wave, ideally stored the moment the submit returns, so a crashed script can rebuild the list and call jobs_result again. For the single-job HTTP behavior behind this, see the jobs_result 409 job_not_completed explainer.