fix(workspace-forking): keep a repointed custom block's inputs configurable after the mapping is saved

[icecrasher321]

Summary

Mapping a custom block to a different block and syncing showed "no changes required" with no fields to fill — so the target-input configuration added in #6871 was unreachable on every sync after the one where the mapping was picked.

parentChanged comes from shouldReconfigureEntry, which asks whether the target was edited in this session. Saving the mapping makes it false, and isDependentConfigurationActionable then keeps only fields that are both required and empty — so an optional input vanished entirely, and a filled required one never came back.

That test is correct for every other kind: an unchanged credential or table mapping leaves its stored dependent picks valid, and a Gmail label picked under the same credential still resolves. A custom block has no such continuity. Its sub-blocks are keyed by the SOURCE block's Start field ids, so under a different target they describe fields that do not exist and nothing carries over. The mapping standing is the reason to configure it, regardless of when it was made.

So: a custom block mapped to a different block is always actionable. Mapped to itself — "keep the same block across environments" — it is not, since its own field ids still describe it. An in-session re-pick still wins over the saved target.

Type of Change

• Bug fix

Testing

turbo run type-check (24/24), check:api-validation, biome clean. 644 fork tests green, 5 new.

shouldReconfigureEntry is now exported and directly covered — it is the one predicate the inline render, the Sync gate, and the payload build all share (its own docstring says so), so it is the right place to pin this rather than asserting through the rendered tree. Cases: settled non-custom-block mapping, saved custom-block mapping to a different block, identity mapping, in-session re-pick overriding the saved target, and unmapped.

Reviewers should focus on whether "always actionable while pointed elsewhere" is the right rule, versus something narrower like "actionable until every required field has a stored value". I went with the broader rule because a custom block's optional inputs are just as unreachable under the old behavior, and there is no stored state that makes them safe to hide.

🤖 Generated with Claude Code

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

1 Skipped Deployment

Project	Deployment	Actions	Updated (UTC)
docs	Skipped		Aug 20, 2026 12:35am

[cursor]

PR Summary

^{Cursor Bugbot is generating a summary for commit ac50f6e. Configure here.}

[greptile-apps]

Greptile Summary

The PR keeps dependent input configuration actionable whenever a custom block remains mapped to a different block, while leaving identity and unmapped mappings settled.

• Exports the shared shouldReconfigureEntry predicate for direct testing.
• Special-cases repointed custom blocks so saved mappings continue exposing required and optional inputs.
• Adds coverage for saved mappings, identity mappings, in-session target changes, and unmapped custom blocks.

Confidence Score: 5/5

The PR appears safe to merge, with the changed predicate preserving saved dependent values while restoring access to repointed custom-block inputs.

Persisted custom-block values are overlaid into the diff response and reused by both validation and payload construction, so keeping repointed mappings actionable does not clear values or block already-configured subsequent syncs.

Important Files Changed

Filename	Overview
apps/sim/ee/workspace-forking/components/fork-sync/use-fork-sync.ts	Makes repointed custom-block mappings continuously actionable while preserving settled behavior for identity and unmapped mappings; persisted dependent values remain reusable.
apps/sim/ee/workspace-forking/components/fork-sync/use-fork-sync.test.tsx	Adds focused predicate coverage for saved repointed mappings, identity mappings, in-session overrides, and unmapped custom blocks.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
  A[Resolve effective target] --> B{Target present?}
  B -- No --> C[Not actionable]
  B -- Yes --> D{Custom block?}
  D -- No --> E{Suggested or changed this session?}
  E -- Yes --> F[Actionable]
  E -- No --> C
  D -- Yes --> G{Target differs from source?}
  G -- Yes --> F
  G -- No --> C
  F --> H[Show dependent inputs]
  H --> I[Reuse persisted values from diff]
  I --> J[Validate required inputs and build sync payload]

Loading

_{Reviews (1): Last reviewed commit: "fix(workspace-forking): keep a repointed..." | Re-trigger Greptile}