OpenOutpainter Serving Input TXT2IMG

This is the front door of the text-to-image half of the pack. When you hit generate in openOutpaint and it POSTs to /sdapi/v1/txt2img, the OpenOutpainter Serving node picks up the request and hands it to this node, which tears the JSON apart and dumps every field onto the graph as a typed output. It's the same role a sampler input box plays in a normal workflow, except the values come from the canvas instead of your fingers.

How it works

The node takes one required input - oop_request, straight from the Serving node - and it's lazy: it asks ComfyUI to only evaluate it when there's actually a request to process. If the pending request isn't a txt2img command, or there's no request at all, it returns an ExecutionBlocker on every output and the whole downstream branch sits dead. The source comments admit lazy evaluation "does not work for some reason," so there's a belt-and-braces check in the main function too. Either way, the practical effect is the same: this node lights up only for txt2img jobs, and its sibling IMG2IMG input node lights up for those.

When it does fire, you get prompt, negative_prompt, width, height, SEED, steps, cfg_scale, batch_size, and n_iter.

Wiring it up

You're basically reconstructing a text-to-image pipeline by hand:

• prompt / negative_prompt → your CLIPTextEncode nodes.
• width / height → the Empty Latent Image node (or the model's native resolution).
• SEED, steps, cfg_scale → KSampler's seed, steps, and cfg inputs.
• batch_size and n_iter → multiply the work. The canvas sends these, so a user asking for 3 images at once flows straight through.

That's the entire point of the pack: openOutpaint's "options" tab lets you pick a sampler and scheduler, but those are mostly cosmetic - this pack deliberately hands the real sampler choice to the workflow. The API serves placeholder lists for samplers and schedulers ("Configure sampler in workflow") so the canvas UI doesn't complain, then you hardcode the actual KSampler settings in the graph.

Install and troubleshooting

Same pack as the whole family: ComfyUI Manager (search "OpenOutpaint ComfyUI Interface") or git clone https://github.com/without-ordinary/openoutpaint_comfyui_interface into ComfyUI/custom_nodes, then restart. Its one dependency is opencv-python; no model downloads involved - this is pure plumbing.

The usual failure mode: you hit generate in the canvas and nothing happens in the graph. Nine times out of ten that's because this node is correctly blocking because the incoming request isn't a txt2img call, or the workflow wasn't re-queued (check the Serving node's Server status output and make sure request_id changed from -1). The other classic is a mid-graph error leaving the HTTP request hanging - re-run the workflow with the same request_id to complete it. If the canvas's txt2img tab is sending requests but you only see the img2img nodes lighting up, you've wired the wrong Input node to your sampler; each command type needs its matching input/output pair in the same branch.