Response payload too large — includes full input workflow instead of just output

[duongminhphucwork]

Hi team,
The response payload returned by the worker is unnecessarily large because it includes the entire input workflow along with the actual output.

i'm using 5.3.0 version

[TimPietruskyRunPod]

We can't reproduce this on 5.8.5. Just ran a deliberately-large test on a fresh hub deployment with the README's FLUX.1-dev-fp8 workflow (multiple SaveImage + PreviewImage nodes), inspected the raw response, and the workflow is not present in any form:

• Top-level keys: delayTime, executionTime, id, output, status, workerId
• output keys: images (only)
• Each image entry: {filename, type: "base64", data: <base64>}
• 309 bytes of non-image JSON overhead for a 2-image response (vs 764,288 bytes of base64 PNG payload). Zero occurrences of CLIPTextEncode, class_type, KSampler, FluxGuidance, or extra_pnginfo anywhere in the response

The handler constructs the response itself in handler.py:873-896 — there's no code path that copies the input workflow into the output. So if you're seeing the workflow in your response, something in your workflow is producing it as an output (e.g. a custom node that returns the prompt as a text output, or a node that writes the workflow into the response).

Could you share:

1. Exact worker-comfyui version you're on now (you mentioned 5.3.0 originally — please retest on 5.8.5+)
2. The exact workflow JSON that produced the screenshot — even a minimal repro would help
3. The full response payload (with image base64 truncated) so we can see exactly where the workflow appears

If you can confirm with a recent version + repro workflow, we'll dig in. Otherwise this looks like an old-version or custom-node-specific issue.