Suno Retrieve Task (Ace Data Cloud)

Here's the mistake this node exists to prevent. You submit a song, ComfyUI's queue goes green in a second, you assume something broke and hit Run again - now you've paid for the same song twice. The submit was accepted; the song isn't done. Music generation takes minutes, and a green queue entry says nothing about whether the service finished.

Suno Retrieve Task (Ace Data Cloud) is the read side. You hand it a task ID, it asks Ace Data Cloud what happened to that task, and it never submits anything. Query-only means it doesn't cost you a generation, which is why the pack's README is blunt about it: rerun this workflow to poll, never the submit.

What it actually is

This is one of the pack's 19 "Dify tool" nodes - thin, schema-backed wrappers over the tool definitions the Suno Dify plugin publishes, rather than the five hand-built guided nodes.

And there's a name collision: the guided node (AceSunoRetrieve) and this one both display as "Suno Retrieve Task (Ace Data Cloud)". They aren't the same node - the guided one has four outputs and defaults wait_seconds to 240, this one has six and defaults it to 0. If a tutorial's screenshots don't match, check the class name.

How the wait loop works

The mechanism is a plain poll with a deadline: POST /suno/tasks with {"action": "retrieve", "id": <your task_id>}, look at the status, sleep five seconds, ask again - until the status moves off pending or the deadline expires.

Because this call is read-only, the client treats it as safe to retry: up to three attempts with a short backoff if the connection fails, which a paid submit never gets. And with no local model in this pack, waiting costs a queue slot and nothing else.

One timing heads-up: wait_seconds at 240 occupies that slot for four minutes. The pack's own end-to-end test produced a 193-second, 48kHz stereo track, so songs do take a while. Setting it to 0 and rerunning the cheap workflow later is the pattern the author pushes.

The inputs that matter

Three, and two are self-explanatory.

• task_id - paste the ID from your submit node. This is the "same task ID" the whole design hinges on.
• wait_seconds - 0 to 240. 0 is a single instant query; 240 is "hold on as long as I'm allowed to."
• parameters_json - a raw JSON object for anything the fields don't cover; {"id": "<task-id>"} works instead of the widget, since action is forced to retrieve.

There's deliberately no model or action dropdown. This node has exactly one job.

Outputs and wiring

Six strings: status, task_id, media_urls_json, first_media_url, result_json, trace_id. status is the one you read - pending means the service is still working, anything else means there's something to look at. It's also an output node, so it always runs and prints its own status lines; no Preview-as-Text needed.

None of these outputs is audio. Wire first_media_url into Suno Load Audio's audio_url input and you get a ComfyUI AUDIO that Preview or Save Audio will take. media_urls_json keeps every returned link (Suno typically hands back two tracks per generation) if you want to fan them out to separate loaders, and result_json is the cleaned full response for anything else.

When the task isn't done, first_media_url is empty and Load Audio refuses with "Task is pending; retrieve the same task ID again." That error is the system working.

Install

Manager → Custom Nodes → search Suno → publisher acedatacloud, package Suno by Ace Data Cloud (Registry ID ace-suno). The pack's own test notes the Registry didn't list it at test time, so fall back to source:

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

That installs requests and jsonschema - the second checks your payload against Suno's contract before sending, so leave it in. No model downloads, no GPU. Then set the key in the ComfyUI process's environment and restart:

export ACEDATACLOUD_API_KEY='paste-your-key-here'
python main.py

The process part matters: an export in another terminal does nothing for ComfyUI Desktop, and the node's own failure message is exactly that instruction.

Common issues

HTTP 401/403 means the key, its Suno access, its path restrictions, or content policy. HTTP 429 is the rate limit - wait it out and keep the same task ID. Still pending after 240s is normal for a busy queue: rerun only this retrieve workflow, as many times as you like. HTTP 5xx or a timeout doesn't tell you whether the task landed, so check your Ace request history before resubmitting anything paid - the trace_id is the handle. And when the node prints HTTP <code>, don't expect a body: the client deliberately scrubs sensitive response fields, so the trace ID is your debugging path, not the error text.

The larger context, since it decides whether you want this pack at all: the hosted path still wins clean vocals, and the local alternative is ACE-Step if your job is instrumental. And remember the API-node bargain - everything you type here leaves your machine, prompts included.