You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Commit 7b2fa42
Browse filesBrowse the repository at this point in the historyBrowse files
fix(workspace-forking): namespace, type, and single-source a custom block's configured inputs
Four review findings, all real, three of them the same root cause: the dependent
store holds a plain string keyed only by (target workflow, block, sub-block), and
that key carried none of what applying the value correctly needs.
The key now carries the TARGET TYPE and the field's declared TYPE.
Target type, because remapping a block to A, configuring it, then remapping to B
would otherwise pre-fill and submit A's value into any field id the two happened
to share — a different workflow's field of the same name. Namespacing makes that
structurally impossible instead of a rule to remember.
Field type, because the canvas stores a boolean input as a real boolean (its
sub-block is a `switch`), so a stored `'false'` written as text is truthy to the
child workflow. The apply side reads the type off the key and restores it, and
the modal offers a switch rather than a text field. `object`/`array` stay strings:
they are authored as JSON and parsed by the executor.
Separately, the carve-out that keeps a custom block's stored value alive through
its always-true `parentChanged` was applied at the render site, so the modal
showed the stored value while the Sync gate and the submitted payload still saw
blank — required fields looked filled but kept Sync disabled, and optional ones
submitted empty and wiped the stored mapping. It now lives in
`effectiveDependentValue`, the one place all three read through.
Field-type-to-control selection moves out of the component into its own module,
where it sits beside the boolean round-trip constants it has to agree with.
Reported by Greptile and Cursor Bugbot on #6871.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
0 commit comments