GPT Image List Tasks (Ace Data Cloud)

Every cloud-image workflow eventually reaches the same moment: something failed, you're not sure whether the request actually went out, and the only way to find out is to ask the service what it has on file. That's this node. It's the pack's read-only query surface over the task endpoint - the accounting desk, not the printing press.

What it's for

Looking up what exists without creating anything. Read-only queries are explicitly not supposed to generate a new paid task, and the client knows the difference: it flags query actions as read-only and allows retries on them, which it refuses to do for a paid submission. So using this node is cheap in a way that re-running a generate is not.

Practical uses: confirming that a job you thought you lost actually exists (grab the id from the response and feed GPT Image Retrieve Task), auditing what your key has been spending, and paging through recent work by type and time. If your realistic need is "give me the outputs for these exact IDs," the sibling batch node is a better fit - but if you don't have the IDs yet, you start here.

The inputs that matter

There is no required field. action is the one real decision: retrieve for a single record, retrieve_batch for a set. Leave it on the sentinel and the service default - retrieve_batch - applies.

Then you identify what you're looking for. id is a single task ID; trace_id is the trace value the service returns alongside it; ids and trace_ids take arrays, and since each of these widgets is a string, you give them a JSON array or one value per line - both parse. Alongside those: application_id and user_id (filters you'll rarely set), type to narrow to images, images_generations or images_edits, offset and limit for paging, created_at_min and created_at_max as numeric epoch bounds, and count_mode as none or exact.

parameters_json accepts the same fields as a JSON object and is the sane way to write a big filter set; any non-empty widget overrides its JSON counterpart. Numbers get coerced from strings, so limit of 20 works fine as text.

Reading the outputs

This is the part that surprises people. The six outputs are status, task_id, media_urls_json, first_media_url, result_json and trace_id - and for a listing, status is the status of the query, not of the jobs inside it. Don't read succeeded as "my image is done." The actual state of each task, plus its response payload and its media URLs, is in result_json; the client harvests every media URL it can find into media_urls_json for convenience. Splat result_json into a PreviewAny and you'll see the whole structure, which is the fastest way to learn what the service actually returns for your account.

Worth knowing if you're comparing this with the batch node: that one normalizes each task individually and will tell you pending or failed per batch, while this node hands you the payload mostly as-is. Different tools for the same endpoint.

Install

Part of the pack - nothing extra to add. Manager: search GPT Image, publisher acedatacloud, package GPT Image by Ace Data Cloud; registry ID gpt-image. If Manager doesn't show it:

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

Restart afterwards. Set ACEDATACLOUD_API_KEY - or ACEDATACLOUD_API_TOKEN - in the environment of the process that runs ComfyUI, not in your shell profile somewhere else, and restart so it's picked up. Dependencies are just requests and jsonschema.

Where people trip

Empty response, assumed breakage. With no identifiers and no filters you're asking for "recent things," and what comes back depends entirely on what the service returns for that. If you get nothing useful, narrow it - add type, add a time window, or supply the id you actually care about.

Expecting this to be a full history view. It's a query over tasks keyed by whatever you give it, paged by offset/limit. Treat it as an API call with a UI, not as a dashboard.

Reading status as task state. For the third time, because this is the actual trap: check result_json for the job's own state.

Paying to re-do work you already paid for. A failed submit is not a failed task. Before you spend credits on the same prompt a second time, list, find the ID, and retrieve it.