Comfy-Org / Comfy-Org/ComfyUI_frontend
Formalize the workflow to execution payload transform proposal (frontend graph preprocessing)
- Dominant language
- TypeScript
- Stars
- 2k
- Forks
- 699
- Avg merge
- 1d 7h
- Merged PRs (30d)
- 490
Description
Ben Cooley's proposal from the 2026-08-21 API v2 discussion is not written down anywhere, has no owner, and is a dependency of Agent, Hub app mode, MCP and the developer platform.
## The problem
The workflow file (save format) should be the canonical representation, with a deterministic transform into the execution representation (API format, server payload). Today part of that transform happens implicitly in scattered frontend code:
* Easy-Use "use everywhere" variables, values implicitly shared across distant nodes
* KJNodes get/set nodes, another graph-level variable and reference form
* link rewrites
* subgraphs and other preprocessing
Any system that reads, modifies or executes a Comfy workflow without our frontend either cannot faithfully execute some workflows, or has to independently reproduce frontend-only behaviour.
## The proposal, as an additive bridge
No break to the existing workflow format or execution API:
1. Centralize the behaviour behind one transform and resolution layer instead of scattered frontend code.
2. Encode enough about those transforms in the workflow to make them replayable outside the frontend.
3. Optionally persist both the workflow and the resulting API payload, with version and provenance information sufficient to reproduce or validate the conversion.
Mental model: workflow, then explicit transforms, then execution payload. The execution payload stays derived state, never a second source of truth.
## What this ticket is for
1. Write the proposal up properly. **Mark clearly which parts are Christian's reconstruction rather than Ben's words**, because there is no transcript of the meeting. Fireflies has no August meetings at all, and a targeted search for this one (attendees Ben, Alex, Christian, 2026-08-21 around 2pm PT) returns nothing.
2. Validate viability against the current save and API formats.
3. Decide whether it can be enforced as a standard for new code, which was the specific ask.
4. Get Ben to confirm or correct it before it goes into any ledger.
Related: FE-1577 (V2 API surface) covers the extension API rather than the graph transform, but the two land on the same consumers.
## Provenance
Christian Byrne, Slack `#p-frontend-graph-improvements`, 2026-08-22T08:33:50Z, thread `p1787387630437609`. The transcript lookup came back empty, so this text is reconstructed from that message.
---
_Mirrored from Linear [FE-1816](https://linear.app/comfyorg/issue/FE-1816/formalize-the-workflow-to-execution-payload-transform-proposal)._
Contributor guide
Research direction
Start by reviewing the current workflow save format and execution API format, then compare them with the listed frontend preprocessing behaviors. Use related issue FE-1577 for the API-surface context. Done means a documented proposal that distinguishes Christian's reconstruction, assesses viability, states whether new code should follow the standard, and records Ben's confirmation or correction.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- typescript
- Domain
- documentation, frontend
- Issue type
- Documentation
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Active
- Clarity
- Mostly clear
- Newbie friendliness
- 25/100