RemRun Deserializer Output (Internal)

This is one of the pack's internal nodes - the category in the menu literally says Remote Run/__Internal__/. You will basically never drag it into a graph by hand, and that's fine. It's the inbox that runs on the remote instance, receiving the data your local machine shipped across and handing it to the rest of the remote subgraph.

If you open a saved workflow from this pack and spot a Deserializer Output node sitting in the graph, it's not a mistake - it's the pipeline working. Leave it alone. Delete it and the remote half of the run breaks in confusing ways.

What it actually does

The node is built around paired inputs: input_N_info and input_N_data for each channel. The _info string tells the node what kind of thing it's holding, and there are three cases:

• INPUT - a plain constant passed straight through.
• serialized - a base64 blob that gets deserialized back into a tensor or whatever object it was on the local side.
• request - the lazy-transfer path. The remote node announces it needs a piece of data via a NEED_DATA websocket message back to the local machine, which then POSTs the actual bytes to the /remote_run/data/ endpoint. Big tensors only travel when the remote actually asks for them, which is how the pack avoids shipping gigabytes on every run.

It has up to ten wildcard outputs, and whatever lands on them feeds the rest of the remote graph.

The inputs you'll see in a workflow

• input_N_info / input_N_data - the pairs above, generated automatically.
• total_timeout and request_timeout - inherited from whichever Remote Run node expanded this graph; they govern how long the node will wait for lazy data to arrive.
• is_changed - same force-a-rerun toggle as the other nodes.

That's it. There's nothing here to tune for a normal run; all the settings came from the node that built the graph.

When it misbehaves

The one error you're likely to actually hit is No client connected to request data from. The lazy-transfer path works by asking the local ComfyUI session for data, which means there needs to be a connected UI client. If you're firing prompts at ComfyUI purely through the API with no browser session attached, the data request has nowhere to go and the remote run stalls or errors. This is a real gotcha of the whole pack: it leans on the websocket connection to your ComfyUI frontend, not just the REST API.

So if a remote-run workflow randomly fails on the far side and the log points at a Deserializer node, your first move is to check that you actually have the ComfyUI web UI open on the local machine, not just a script hitting the API. Annoying, but it's how the lazy-transfer magic is wired.