2. NewAPI Query Video Tasks

Video generation is slow, and the maomao pack's submit node doesn't wait around. NewApiQueryTasks is the middle of the three-node chain: it checks whether your submitted jobs are done - and, when the upstream relay chokes, it quietly resubmits them for you. That second part is why you care about this node, and also why you should watch your credit balance.

How it works

Every task the submit node created lives in newapi_video_tasks.json in the pack folder. This node reads that file, and for each task that isn't already finished with a video URL it polls the relay with GET {relay}/v1/videos/{task_id}. Fresh status gets written back to the JSON so the download node knows what's ready.

The clever bit is the retry logic. The submit node saved the original request payload with each task, so when a poll comes back failed, this node can resubmit the exact same job as a brand-new task - up to max_retries times (the value you set on the submit node, default 3). It only does this for transient failures: HTTP 408 and 429, server_error, timeout_error, "system under load", "try again later", that family. A genuine failure just gets reported.

There's also a guard that keeps a retry chain from respawning forever: once any task in the same retry root succeeds, further automatic retries in that chain stop. The author's test log explains why this exists - the relay happily accepted submissions but then failed to complete the actual video with server_error at high progress, or bounced Veo jobs during handoff with 408 timeout_error: system under load and 429. Retries are the patch for that, and the guard is the patch for retries.

Inputs (all optional)

• api_key - without it, the node reads the local cache only: no network calls, no retries, just a status dump of what's on disk. Hand it a key and it actually polls.
• max_items - how many tasks the report lists, 1–200, default 20.
• auto_retry_failed - the big switch, on by default. Turn it off if you'd rather see failures than pay for re-submissions.

Output

report, a STRING - a multi-line text dump, newest tasks first. Each line gets a [已成功] (succeeded) / [失败] (failed) / [进行中] (in progress) prefix, the status, a progress percentage, the task id, the upstream task id when there is one, and a note once the video URL is ready. Failures get a reason line; retries get a 自动重试：old -> new line. It's readable and genuinely useful, and it is emphatically not structured data - don't build automation on parsing it.

Where it fits

Wire nothing into it; run it a few minutes after a submit. The report tells you what's ready, and once a task shows a video URL you hand off to the download node. Because all three nodes run on every queue pass (the NaN IS_CHANGED trick), you can leave query in the graph and let it keep refreshing - each run is a few HTTP calls per job, not a big deal.

Install

Via ComfyUI Manager, search maomao, install, restart. Or:

cd ComfyUI/custom_nodes
git clone https://github.com/xiaohuangzhengbang/maomao

Restart ComfyUI. No requirements.txt, no model downloads - the pack only needs requests, numpy, and Pillow, which ComfyUI already has. This is one of three nodes in the pack (submit, query, download) that share the task file and the relay connection.

Troubleshooting

If the report says 未提供 API Key，本次仅显示本地缓存状态 ("no API key, showing local cache only"), you left the key blank - expected, but easy to mistake for a bug. If auto-retry is on and your credit balance is draining faster than jobs complete, the relay is in its flaky phase; drop max_retries on the submit side or flip auto_retry_failed off here. A task that crawls to 90% and then fails with server_error is upstream, not you - surviving exactly that is the whole point of this node.