jobs_wait fails on one unknown job id: why and how to avoid it

On Sume's remote MCP, jobs_wait fails the whole call if any id in job_ids is unknown or belongs to another workspace. You do not get partial snapshots for the good ids, so one stray id costs the entire wait.

The fix is on your side: only wait on ids your own session created in the workspace you are connected to, and keep a clean list of them from the moment each submit returns.

What exactly happens with a bad id?

The Jobs and results page states it in one line: unknown or foreign-workspace ids fail the whole call. That is different from jobs_result, where a batch is deliberately partial and each entry carries its own ok.

For the HTTP API the closest documented behavior is 404 not_found, defined as a resource that does not exist in the current workspace. A job id from another workspace and a mistyped id look the same from your side, and the docs do not distinguish them.

How do ids from another workspace end up in my list?

The usual causes are boring. Ids copied between environments, a script that switched API keys between runs, a prompt that told an agent to wait on an id it saw in a different thread, or a typo when an id was pasted by hand. Because the workspace is determined by the key or session you connect with, the same id can be valid with one key and unknown with another.

An agent can also invent an id. If a model writes job_ids from memory rather than from the submit response, it can produce plausible ids that do not exist. Give the agent the ids from tool results, not from its own recollection.

What is a robust way to wait?

Record each id when the submit returns, keep it in a list tied to the workspace, and wait only on that list:

• Store job_id (the submit response's request_id on HTTP) immediately after each paid create.
• Cap each batch at 20 ids, the documented ceiling for jobs_wait.
• If a wait fails outright, check ids with a single jobs_status before retrying the batch. A single-id read isolates the bad one.
• Never resubmit the paid create to "fix" a failed wait. The jobs exist and keep billing.
• Retry jobs_wait with the same corrected ids on wait_slice_expired.

How does this compare with the HTTP status endpoint?

Over HTTP each status read names a single job, so a bad id fails only that read. A script that polls ten jobs one by one can log the 404 for one id and keep going. The MCP batch wait trades that isolation for fewer round trips, which is why the id hygiene above matters more there.

Treat the first failure as information about your list, not about the jobs. Look for the id that differs from what the submit returned, and rebuild the list from stored submit responses if you cannot find it.

Is the failure a job failure?

No. The call fails because the request names something Sume cannot resolve, not because a job reached a terminal state. Nothing about your real jobs changed. Once you remove the bad id, the wait works as before, with the same 50-second default slice and 55-second cap.

If you want to read more on slicing and batch waits, the parallel jobs_wait any versus all post is the closest companion.