Nodes/comfyui_bmad_nodes/SetRequestStateToComplete
ComfyUI Node Runs on cloud

SetRequestStateToComplete

SetRequestStateToComplete closes out an API request

By bmad4ever·Created 3 years ago·Updated 9 months ago· 70
SetRequestStateToComplete
  • resource_0

    SetRequestStateToComplete is a punctuation mark. It's the node at the very end of the bmad API flow that tells the outside world "this request finished successfully," by flipping the request's status file to complete and clearing the internal request id so the next request can start fresh. It takes no parameters you'll care about and produces no data - it's an output node whose only job is signaling.

    Here's the full loop this node closes. CreateRequestMetadata writes a JSON status file (starting with "state": "started") into ComfyUI's output folder, keyed by the request id. Your generation runs. Save Image (api) saves your images and registers them in that same file under a resource name. Then you wire its TASK_DONE output into this node, and when it executes it sets "state": "complete" in the JSON and clears the request id.

    Save Image (api) --TASK_DONE--> SetRequestStateToComplete
    

    A caller polling that status file now sees complete and knows it can read the outputs that were registered. It's a simple, file-based handshake - no sockets, no callbacks, no webhooks. For a small internal setup that's plenty; it's also exactly the kind of thing the pack's author waves off in the README, noting that purpose-built API solutions are better documented and more complete. Take that as fair warning if you're building something big.

    The input that matters

    • resource_0 - expects a TASK_DONE token, which is what Save Image (api) outputs. The fact that it's a typed input rather than a free-for-all is the guard rail: you can't mark a request complete before the work that's supposed to produce the outputs has actually run. Wire the saver's output here and the ordering is enforced by the graph.

    There are no outputs. The node is is_output_node - it exists for its side effect on the request file.

    Gotchas

    The obvious one: this node needs CreateRequestMetadata somewhere in the workflow to have set a request id, because it writes to that node's status file and then clears the id. Run it with no request metadata in the picture and you'll get an error about the missing/empty request id. And because it clears the id after completing, two requests in the same ComfyUI session are fine as long as each prompt carries its own CreateRequestMetadata - which is also why that node insists there's only ever one of it in a workflow.

    Installing

    Ships in comfyui_bmad_nodes. ComfyUI Manager - search "comfyui_bmad_nodes" (or "Bmad Nodes") - install, restart. Manual:

    cd ComfyUI/custom_nodes
    git clone https://github.com/bmad4ever/comfyui_bmad_nodes
    cd comfyui_bmad_nodes
    pip install -r requirements.txt
    

    Restart after; no model downloads, and this node needs nothing beyond the pack itself.

    CategoryBmad/api

    Inputs (1)

    NameTypeDefaultDescription
    resource_0TASK_DONE

    Outputs (0)

    No outputs