Midjourney Retrieve Tasks (Ace Data Cloud)

What it is

The plural version of Retrieve Task. Same idea, one call: hand it a list of task IDs, get the status and media URLs for all of them back. The README's framing is the right one - "retrieve existing tasks by ID without repeating generation."

When you actually want it: you ran a batch of generations (through several Imagine nodes, or the same node queued repeatedly), the graph fell over, and you need the results without spending a credit. Or you're closing a session and want one node that drains everything you launched in the last hour into a single place. This is a recovery and housekeeping node, not part of the happy path - and it's genuinely good at that job.

How it works

Under the hood the contract fixes action to retrieve_batch, so the batch mode is baked in rather than something you select on the node - the /midjourney/tasks endpoint is the same one the single-retrieve node uses, with a different action. That's why the schemas look so similar.

The IDs come in through ids_json: a multiline string containing a JSON array, minimum one entry, like ["task-a", "task-b"]. Paste a single bare string and the node stops you with "ids_json must be a nonempty JSON array of task IDs." There's also a trace_ids widget (also parsed as JSON) if you're identifying work by request trace instead, plus offset and limit for paging through a longer list.

The aggregating behaviour is the part worth understanding before you read the output. media_urls_json is every media URL found across all the returned tasks, flattened into one list. result_json holds the per-task items. And status is a summary, not a per-task report: pending if any task is still running, failed if any task failed, succeeded only if everything came back clean. One straggler in a batch of twenty will show the whole node as pending, which is correct but occasionally annoying.

Inputs and outputs

• ids_json (multiline) - the JSON array of task IDs. This is the field you set.
• trace_ids - JSON array of trace IDs, alternative lookup. Usually empty.
• trace_id - singular, for a single trace lookup. Usually empty.
• offset / limit - paging controls for long result sets, entered as text and coerced to integers.
• parameters_json - the shared JSON hatch, {} by default.
• Outputs (all STRING): status, task_id, media_urls_json, first_media_url, result_json, trace_id. Note task_id and trace_id are normally empty here - there isn't one task. The useful ones are status, media_urls_json and result_json.

Install

ComfyUI Manager → search Midjourney → publisher acedatacloud, package Midjourney by Ace Data Cloud (Registry ID midjourney) → install → restart. Or:

cd ComfyUI/custom_nodes
git clone https://github.com/AceDataCloud/MidjourneyComfyUI
cd MidjourneyComfyUI
python -m pip install -r requirements.txt

Export ACEDATACLOUD_API_KEY into the environment ComfyUI runs in and restart it. Dependencies are requests and jsonschema, nothing heavier.

Common issues

"ids_json must be a nonempty JSON array of task IDs." Either it isn't valid JSON, or it's not an array, or it's empty. Double quotes, square brackets, comma-separated strings - a line-separated list will not work here.

One failure sinks the status. As above: any failed task in the batch and the top-level status reads failed, even if nineteen succeeded. Parse result_json when you need the detail; the summary string is a smoke alarm, not a report.

Don't expect it to be free of consequences. Read-only queries aren't supposed to create new paid tasks, and this node is a query - but the rule depends on the service honouring it, so check request history if a session's accounting looks off rather than assuming.

Using it as your primary result path. You can wire media_urls_json straight into a loader, but you're then relying on first_media_url being the one you wanted, out of a flat list of everything. For a single deliberate generation, the singular retrieve node is the better habit. This one earns its place when there are already several tasks and you want them all.

Watch the list size. The API is billed and rate-limited like any other; a hundred IDs in one widget is an unusual thing to send and more likely to be throttled than a handful of smaller calls.