Nodes/RunningHub/RH Task Outputs
ComfyUI Node

RH Task Outputs

RH Task Outputs grabs the results of a cloud job you already know the ID for

By liangzheng1128·Created 3 months ago·Updated 3 months ago· 0
RH Task Outputs
    • images
    • output_urls
    • task_id
    api_key
    base_urlhttps://www.runninghub.cn
    task_id
    wait_for_resulttrue
    timeout300

    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_key and base_url - your RunningHub credentials, pasted directly on the node (the Task nodes skip RH Settings' STRUCT config, 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 to timeout seconds) 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 when wait_for_result is 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.

    CategoryRunningHub

    Inputs (5)

    NameTypeDefaultDescription
    api_keySTRING
    base_urlSTRINGhttps://www.runninghub.cn
    task_idSTRING
    wait_for_resultBOOLEANtrueWait until task completes
    timeoutINT3001–9999999

    Outputs (3)

    NameTypeDescription
    imagesIMAGE
    output_urlsSTRING
    task_idSTRING