Nano Banana Retrieve Task (Ace Data Cloud)

The single most expensive mistake with this pack is pressing Queue to see if your image is done yet. Generate and Edit are paid submissions. Retrieve Task is a free read. Once that clicks, the whole two-node design of this pack stops feeling awkward and starts feeling deliberate.

Because Nano Banana generations are async - the submit call returns a task ID, not pixels - something has to go ask the API whether the job finished. That's this node.

How it works

It POSTs {action: "retrieve", id: <task_id>} to /nano-banana/tasks and normalizes the answer into a status. Three outcomes matter: succeeded with image URLs attached, pending with nothing yet, or a hard failure like a task that was rejected or finished without producing an image.

The polling loop is simple and honest. It checks, and if the task is still pending it sleeps - up to five seconds, or whatever's left of your deadline - and checks again until the wait runs out. If the wait expires while the task is still going, it returns pending rather than erroring, because pending is a real state and not a failure.

Crucially, lookups are the only calls in this pack that retry. Read-only requests get three attempts with a short backoff; the paid submissions get one. The client's own docstring says it plainly: paid submissions are sent once, only lookups and media downloads retry. Somebody thought about your wallet.

Inputs and outputs

• task_id - paste the ID from Generate/Edit, or wire the task_id output across. Most people do the wiring once and forget it.
• wait_seconds - 0 to 240, default 240, step 5. This is your patience budget for one run, not a timeout on the task itself. Set it to 0 and the node does a single check and returns immediately, which is what you want if you're building a workflow that runs on a schedule and shouldn't sit there holding the queue.

Outputs, all strings:

• status - succeeded or pending.
• task_id - echoed back, so you can chain or log it.
• image_urls_json - JSON array of the finished image URLs, [] while pending. Wire to Load Images.
• first_image_url - the convenience output. Wire straight to Load Image; empty string while pending, which is what triggers that node's "still pending" error.
• trace_id - for support.

The node also prints status lines into its own UI panel, so you get a readable "Nano Banana status: pending" without wiring anything up.

Install

Manager → Custom Nodes → search Nano Banana (publisher acedatacloud), install, restart. Or from source:

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

Just requests, plus the key in the process environment:

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

The README ships an example workflow (examples/02-retrieve-and-preview.json) that does Retrieve Task → Load Images → Preview Image and waits up to 240 seconds. Import it, drop in your task ID, run.

Where people get burned

Still pending after 240 seconds. Normal for a busy service. Re-run only the retrieve workflow - repeatedly. Never re-run Generate to "get it moving"; that's a second paid job.

"Nano Banana task failed." The job was rejected, cancelled, or refused. Check the task and trace IDs in the Ace console. Sometimes it's moderation, sometimes it's a transient service error, and the node deliberately won't tell you which.

"Task finished without an image URL." Succeeded status, nothing to download. Rare, usually a truncated response - retrieve again before assuming the worst.

Long waits block your queue. A 240-second wait holds a ComfyUI execution while nothing is generating locally. If you're running a queue of other work, keep it low, or set it to 0 and retrieve later - the lookup doesn't expire.