Grok Video Retrieve Tasks (Ace Data Cloud)

The night this node earns its keep is the one where ComfyUI died mid-queue, or you cleared the console, or you generated eleven clips and only saved two. Every one of those tasks is still on the service and still belongs to you. This node asks about all of them at once, and it doesn't spend a credit doing it, because a batch retrieve is a read-only query.

It's the plural twin of the single-task retrieve node. Same endpoint, same free status, one difference that matters: instead of a task_id string you give it a JSON array of IDs, and instead of one task's media you get back a flattened pile of every URL in the batch.

The two inputs

• ids_json - a multiline STRING holding a JSON array:

  ["9f2c1e7a-...", "1b40d3c8-...", "77aa90fe-..."]

  It's validated before anything is sent, and the errors are unusually clear: ids_json must be a JSON array of task IDs. for a parse failure, ids_json must be a nonempty JSON array of task IDs. for [] or a stray object. Python-style single quotes are not JSON, so ['a','b'] fails - that's the mistake to expect, because the IDs are long enough to hand-edit, and hand-editing is how quotes get sloppy.
• parameters_json - leave it {}. The action is fixed to retrieve_batch by the API contract, so there is nothing for you to set here.

What comes back, and how the aggregation works

The client sends one POST with action: retrieve_batch, then finds the list of tasks in the response (whether the service hands them back as a bare array or under items / tasks / data) and normalizes each one individually. That per-item pass is the part I like: if one entry can't be normalized, it becomes a failed entry with its ID intact rather than taking the whole call down with it. One dead ID in a list of twenty still gets you the other nineteen.

Then it aggregates, and this is where you have to read carefully:

• status is pending if any task is still pending, otherwise failed if any failed, otherwise succeeded. So a batch of ten finished clips plus one still rendering reports pending - correct, but it hides the nine that are ready. Filter on result_json's per-item entries rather than trusting the top-level status.
• media_urls_json is every URL from every task, concatenated in order, deduplicated.
• first_media_url is the first URL of the first task that has media. Convenient for a single clip; misleading for a batch, and it does not tell you which task it came from.
• task_id is an empty string here. Nobody is echoing your list back at you, so keep the IDs somewhere you can see them - a note node next to the batch node, or the workflow JSON itself.
• result_json carries items, and each item has its own status, task_id, media_urls and payload. This is the output that actually answers "which of my clips is done?"

Note the difference from the single-task node: here a failed task shows up as a failed status instead of raising an exception. A batch that includes one dead ID should not blow up your run, and it doesn't.

Practicalities

No wait_seconds on this one - there's no polling loop and no deadline, so it returns as soon as the service answers. The client's read timeout for that round trip is 60 seconds, which is the real ceiling on list length; keep batches to a few dozen IDs rather than a few hundred.

It's the right way to answer "did that expensive run actually land?" without re-submitting anything. Full wiring, for the recovery case:

AceGrokGrokTasksRetrieveBatch ── first_media_url ──► AceGrokLoadVideo ──► save / interpolate / upscale

Install

Manager → search Grok → publisher acedatacloud, package "Grok by Ace Data Cloud" (registry ID grok), install, restart. Manually:

cd ComfyUI/custom_nodes
git clone https://github.com/AceDataCloud/GrokComfyUI
cd GrokComfyUI && python -m pip install -r requirements.txt
export ACEDATACLOUD_API_KEY=your_key_here   # restart the ComfyUI process after this

Two small dependencies (requests, jsonschema), no model downloads, no GPU. The loader that consumes first_media_url needs ComfyUI 0.39.0 or newer, since it returns a native VIDEO.

Where people get burned

Reading the batch status as the whole truth. pending because one job is still going is not the same as "nothing is ready." Open result_json.

Expecting credits back. Querying is free by design; nothing this node does can undo a submission you already paid for. It only stops you from paying again.

A 401 that looks like a bad ID. An unknown ID and a bad API key both end in an HTTP error line. If every ID in the batch fails, check the key in the process environment before you go hunting for typos in UUIDs.

Assuming the CDN links live forever. They're what the loader needs, and they're what you should be capturing into a file the moment a batch reports success.