In ComfyUI workflow JSON, what does the top-level 'version' field mean, and which fields actually record the frontend and node-pack versions?
Problem. People read workflow 'version' as an application version and then cannot explain why a workflow made on one frontend misbehaves on another. Conditions. Comfy-Org/ComfyUI_frontend commit 174bd880 (package.json version 1.59.0), workflowSchema.ts and src/scripts/app.ts. UI-format workflows only (API-format prompts have no such field). Method. (1) The validator reads only a numeric 'version'; if it equals 1 it applies the schema-version-1 definition, and anything else is validated as the older 0.4 schema. So 'version' is a graph-schema number, not a ComfyUI or frontend release. (2) The frontend release that saved the file is recorded separately as extra.frontendVersion (optional string). (3) Each node can carry properties.cnr_id (registry id), properties.aux_id (github user/repo for non-registry packs) and properties.ver, which must be a semantic version, a git commit hash or 'unknown'. (4) Optional models arrays at graph or node level list model files (see C3-B574-09 for hashe...
Structured fields
{
"citations": [
{
"url": "https://raw.githubusercontent.com/Comfy-Org/ComfyUI_frontend/174bd880787b177f408cb73752bccc1d2ca720cc/src/platform/workflow/validation/schemas/workflowSchema.ts",
"note": "validateComfyWorkflow; validateComfyWorkflow; zExtra; zProperties; loadGraphData"
},
{
"url": "https://raw.githubusercontent.com/Comfy-Org/ComfyUI_frontend/174bd880787b177f408cb73752bccc1d2ca720cc/src/scripts/app.ts",
"note": "validateComfyWorkflow; validateComfyWorkflow; zExtra; zProperties; loadGraphData"
}
]
}Evidence claims
- [sourced_fact] Problem. People read workflow 'version' as an application version and then cannot explain why a workflow made on one frontend misbehaves on another. Conditions. Comfy-Org/ComfyUI_frontend commit 174bd880 (package.json version 1.59.0), workflowSchema.ts and src/scripts/app.ts. UI-format workflows only (API-format prompts have no such field). Method. (1) The validator reads only a numeric 'version'; if it equals 1 it applies the schema-version-1 definition, and anything else is validated as the older 0.4 schema. So 'version' is a graph-schema number, not a ComfyUI or frontend release. (2) The frontend release that saved the file is recorded separately as extra.frontendVersion (optional string). (3) Each node can carry properties.cnr_id (registry id), properties.aux_id (github user/repo for non-registry packs) and properties.ver, which must be a semantic version, a git commit hash or 'unknown'. (4) Optional models arrays at graph or node level list model files (see C3-B574-09 for hashes). (5) Legacy 0.4 files get a reroute-migration toast. Failure modes. Validation is advisory: the loader keeps the unvalidated graph if validation fails ('Ideally we should not block users from loading the workflow'), so a malformed or newer workflow can still half-load; ver may be 'unknown', so it is not a reliable pin; the version field says nothing about which node-pack commit produced widget layouts (inference). Example. A file with version 0.4 and no extra.frontendVersion predates the fields above. Limitations. Frontend source read at one commit; behaviour on other releases not checked. Version and date. Frontend 174bd880. · locator: validateComfyWorkflow; validateComfyWorkflow; zExtra; zProperties; loadGraphData source
Rights
| component | license | hosting | redistribution | modification | training | Evidence and notes |
|---|---|---|---|---|---|---|
| documentation | unknown | permitted | permitted | unknown | unknown | Applies to this original summary only, not to the cited sources. |