HTTP node key-value storage: three bugs share one root cause (in-band delimiters in a joined string) — worth a structured model?

[dparkmit24]

Self Checks

• I have searched for existing issues search for existing issues, including closed ones.
• I confirm that I am using English to submit this report (我已阅读并同意 Language Policy).
• [FOR CHINESE USERS] 请务必使用英文提交 Issue，否则会被关闭。谢谢！:)
• Please do not modify this template :) and fill in all the required fields.

1. Is this request related to a challenge you're experiencing? Tell me about your story.

Working in the HTTP Request node's Params / Headers / body tables, I've hit three separate defects that all trace back to one thing: this key-value data is persisted as a single newline-joined, colon-delimited string (key:value\nkey:value), and the editor round-trips list → string → list on every edit. In-band delimiters (\n between rows, : between key and value) plus no stable per-row identity is a combination that keeps producing corruption bugs on different surfaces.

Three bugs, one root cause:

1. Typing into the trailing row destroys it — fix: typing into the trailing Params/Headers row in the HTTP node no longer destroys the row #39552 (fixed). Each keystroke re-derived the list from the string and reassigned every row's id, remounting the editor mid-keystroke.

2. Enter corrupts the row; no keyboard advance — fix(http): stop Enter from corrupting Params/Headers rows; support Enter/Tab to advance #39566 (open). Pressing Enter in a key or value field inserts a literal newline, which the parser reads as a new row boundary, so a value typed before Enter is re-read as the next row's key. There's also no keyboard way to commit a row and advance to the next one.

3. Form-data body values are truncated at the first colon — HTTP node form-data body values are truncated at the first colon after reload #38860, with an open fix in fix: keep colons in HTTP node form body values on migration #38861 (not mine). transformToBodyPayload splits each line on : and keeps only the first segment, so https://host:8080/path becomes https. This is the body path specifically — header/param values already survive colons via others.join(':') — but it's the same in-band-delimiter class biting a different field.

So the header/param surface loses empty/half-typed rows, colons in a key, embedded newlines, and surrounding whitespace; the body surface additionally hard-truncates values at the first colon. Each has a narrow fix, but they're facets of one design choice.

2. Additional context or comments

The question: would you be open to moving this key-value data from the joined string to a structured { key, value, id }[] list with a stable per-row id? That would make these classes structurally impossible rather than individually patched, and give rows a stable identity so the editor doesn't remount on round-trip.

To sanity-check feasibility before raising it, I prototyped the frontend change on a branch (happy to share or open a PR if you're interested). What that prototype found:

• The editor components below the persistence boundary already work on a {key,value,id}[] list — the string only exists at the save boundary — so the frontend change is ~100 lines of conversion code plus a rewritten hook. TypeScript over the whole web workspace confirms only four call sites read these fields as strings.
• Existing saved string data converts to the structured model and back byte-identically, including colon-bearing values, so migrate-on-load is lossless for the shapes the current editor produces.
• The whole app/components/workflow test suite (3139 tests) still passes with the change.
• Most encouraging: this project already accepts exactly this pattern for exactly this node. The body field already carries string | BodyPayload on both sides, with a Pydantic before validator handling the legacy string form. A headers/params migration would follow that precedent one-for-one.

What I did not establish, because it's where the real cost is:

• Backend is untouched. The node's runtime lives in the pinned external graphon package, where headers/params are typed str — a structured list would fail validation today. This cannot ship frontend-only; it needs a coordinated graphon release + version bump. That's the main thing I'd want your read on.
• No live browser verification yet (unit tests + typecheck only), and I've only proven the shapes the current editor emits migrate losslessly — not every historical/hand-authored DSL.

Open questions for you:

1. Would you accept a coordinated graphon + dify release for this, and what's the process/appetite?
2. Which saved-workflow shapes must be treated as in-contract for backward compat?
3. For a node-data shape change, do you expect a DSL version bump, or is a read-path compat shim (the body.data precedent) sufficient on its own?
4. Read-path shim indefinitely (as body.data does today), or a one-time write migration of stored workflows?

If you'd rather keep the string model and just take the narrow per-bug fixes, that's completely reasonable — I mainly wanted to surface that these aren't three unrelated bugs, and that the structural alternative looks tractable on the frontend with a known-precedent backend path.

3. Can you help us with this feature?

• I am interested in contributing to this feature.