RH Task Status

Every RunningHub job you submit comes back with a task_id, and once that ID exists the job has a life of its own - it's running on someone else's GPU, and your local graph doesn't automatically know how it's going. RH Task Status is the little node that asks the cloud directly: what's the current status of this task?

It's a status checker, nothing more. You give it a task ID plus your API credentials, it calls RunningHub's /task/openapi/status endpoint, and it hands you back a status string (RUNNING, QUEUED, FAILED, or whatever the platform reports - the source passes through the raw taskStatus value, so you get RunningHub's own vocabulary).

What you set

Three inputs, all strings, all required:

• api_key - your RunningHub API key (32 characters, from the account menu).
• base_url - defaults to https://www.runninghub.cn; switch to https://www.runninghub.ai if you're on the international site.
• task_id - the task you're checking. This typically comes from the task_id output of RH Execute Workflow, one of the Model nodes (text-to-video, image-to-video), or RH Task Outputs.

Note there's no RH Settings connection here - the Task nodes take their credentials directly on the node, not via the STRUCT config that the Execute nodes use. It's a small inconsistency in the pack, but it means you'll be pasting (or wiring) the key and base URL twice if you're mixing Execute and Task nodes.

Outputs

• status (STRING) - the current task status from the platform.
• task_id (STRING) - echoed back so you can chain this into whatever needs the ID downstream.

Both are marked as output-node-style outputs, which means it's meant to sit at the end of a branch and show you its result. This is a query node, not a driver - it doesn't wait, doesn't download, doesn't retry. If the key or task ID is missing, it returns the literal string Missing API key or task ID as the status, which is at least honest.

When you'd actually use it

Honestly, you'll rarely need it. RH Execute Workflow and RH Task Outputs already wait for completion and pull results - the polling loop is built in. RH Task Status earns its keep in the in-between cases:

• You submitted a job in a previous run and want to check on it without re-running the whole graph.
• You're building a "poll a cloud job on my own schedule" workflow, or a dashboard that monitors a batch of task IDs.
• You want to confirm a task actually finished before you spend money downloading outputs.

It's one of the pack's simplest nodes, and that's the whole appeal: a single HTTP call, no waiting, no side effects. If you need something to do with the status rather than just report it, check the sibling nodes - RH Task Outputs waits and fetches results, and RH Task Cancel stops a running job. This one just tells you the truth about where the job stands.

Install

Ships with ComfyUI-RunningHub:

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. Light deps (requests, websocket-client, Pillow, numpy) - nothing model-sized.