Midjourney Retrieve Task (Ace Data Cloud)

What it is

The most important node in this pack, and the one nobody installs for fun. Imagine, Edits and Videos all submit work asynchronously: they hand you a task_id and return. This node takes a task_id and tells you where that job got to - pending, or done with its media URLs attached.

So the working loop is: submit once, retrieve until it's finished. The retrieval is a read-only lookup against the service, and the README is explicit that read-only task queries and media downloads shouldn't generate a new paid task. That's the difference between a workflow that costs you one generation and one that costs you four because you got impatient.

The pack even ships the two-node example for it: examples/01-configure-and-run.json is just this node with a PASTE_YOUR_TASK_ID_HERE placeholder wired to a preview, and it deliberately submits nothing.

How it works

Two ways to identify a task. task_id is the direct route and the one you want. trace_id is the service's request-trace identifier and works as a fallback - the contract accepts either, and the node errors out early with "A task ID or supported trace ID is required." if you give it neither.

wait_seconds (INT, 0 to 240) turns it into a small poller: the node re-queries the task, sleeping a few seconds between attempts, until the status leaves pending or the budget runs out. It's a bounded wait on purpose - 240 seconds is four minutes, which covers a fast Midjourney job and does not cover a slow one. If the budget expires you get status: pending back with the same task ID, and the correct move is to run the graph again, not to re-submit the generation.

Because lookups go through the read side, the transport treats them differently from paid submissions: lookups retry up to three times on a connection failure, while a paid submit is attempted exactly once and never retried. If you've ever had a flaky connection double-charge you on some other API pack, that's the design decision paying off.

Inputs and outputs

• task_id - the ID from any generator node. Paste it, or wire task_id from a previous node's output if you're keeping it in-graph.
• trace_id - alternative handle, string, usually left empty.
• wait_seconds - 0 means "answer now". Anything higher polls up to that many seconds.
• parameters_json - the shared JSON hatch, {} by default. Leave it.
• Outputs: status, task_id, media_urls_json, first_media_url, result_json, trace_id. When the job is done, first_media_url is the one you wire into the image or video loader; media_urls_json is the full list. While it's pending, both come back empty - the node is careful not to hand you a URL that doesn't exist yet.

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

ACEDATACLOUD_API_KEY (or ACEDATACLOUD_API_TOKEN) needs to be in the ComfyUI process environment, then restart. Dependencies are requests and jsonschema.

Common issues

Pending after a 240-second wait. You waited the maximum and the job still isn't done - likely you're on relax mode, which is deliberately slower. Queue the retrieve node again with the same ID. The job didn't vanish.

"A task ID or supported trace ID is required." Empty lookup. Happens when a generator node failed and its task_id output is an empty string that got wired straight in.

You queued the whole graph again and paid twice. The classic. Re-running an Imagine node costs money; re-running the retrieve node costs (effectively) nothing. Keep them in separate groups, or get in the habit of muting the generator before you hit Queue while debugging.

Typing the ID wrong is silent-ish. You get a lookup failure rather than a wrong image, so nothing dangerous happens - but if a retrieve that worked five minutes ago suddenly stops resolving, copy the ID again rather than retrying the same paste.

Trying to use it as a progress bar. It isn't one. The node resolves at the end and reports a status string; there's no percentage and no streaming. The status text the node prints in its own UI panel (status, task ID, media count) is your feedback while it runs.