RH Task Outputs
RH Task Outputs grabs the results of a cloud job you already know the ID for
- images
- output_urls
- task_id
RH Execute Workflow is the all-in-one: submit, wait, download, done. But sometimes you already have a task ID - from a previous run, from a job you kicked off hours ago, or from another machine - and you just want the results. RH Task Outputs is the node that says "give me the outputs of this specific task," with an optional wait built in.
It hits RunningHub's /task/openapi/outputs endpoint, which is the same call the Execute nodes poll internally. The difference is this node is a standalone tool: you bring the task ID, it brings the fetch.
What you set
api_keyandbase_url- your RunningHub credentials, pasted directly on the node (the Task nodes skip RH Settings'STRUCTconfig, so no connection there).task_id- the job you're fetching.wait_for_result(true default) - the one that changes behavior. If true, the node polls until the task completes (up totimeoutseconds) and then returns the results. If false, it does a single check: if the task is still running it returns the status string instead of results.timeout(300s default) - how long the wait loop is allowed to run whenwait_for_resultis on.
Outputs
Three: images (IMAGE), output_urls (STRING), task_id (STRING).
images is a batched tensor of any image results (downloaded and converted from URLs). output_urls is the interesting one - all result URLs joined into one newline-separated string, which is exactly what RH Split Output URLs is built to split back into individual sockets. So a very natural chain is:
RH Task Outputs (output_urls) → RH Split Output URLs → url1 → RH Download Image
How it behaves
The wait path is the same polling loop as the Execute nodes - status checked every few seconds until done, fail, or timeout. The non-wait path is where it gets a little surprising: if the task is still queued or running, the output_urls output contains a string like Task status: RUNNING instead of URLs. That's intentional - you can use it to check a task's state without committing to a wait - but it means you should only trust output_urls to be actual URLs when you know the task is finished.
Empty or errored runs come back as a black 64×64 placeholder tensor with the problem text in output_urls, which is this pack's standard failure signature - the same one you'll see across the Execute and Model nodes. When results look broken, read that string before you blame the images.
When you'd use it over Execute Workflow
The deciding factor is whether you control the submission. If you're submitting fresh from your graph with parameter overrides, RH Execute Workflow is more convenient - it returns the task ID and downloads everything in one shot. If you're resuming, monitoring, or fetching a job submitted elsewhere, RH Task Outputs is the right tool: just the fetch, no re-submission, no risk of running the job twice (and paying twice).
Install
cd ComfyUI/custom_nodes/
git clone https://github.com/liangzheng1128/ComfyUI-RunningHub
cd ComfyUI-RunningHub
pip install -r requirements.txt
or ComfyUI Manager → search "RunningHub", restart. Standard light deps for the pack - requests, websocket-client, Pillow, numpy.
Inputs (5)
| Name | Type | Default | Description |
|---|---|---|---|
| api_key | STRING | — | |
| base_url | STRING | https://www.runninghub.cn | — |
| task_id | STRING | — | |
| wait_for_result | BOOLEAN | true | Wait until task completes |
| timeout | INT | 3001–9999999 | — |
Outputs (3)
| Name | Type | Description |
|---|---|---|
| images | IMAGE | — |
| output_urls | STRING | — |
| task_id | STRING | — |