## Problem/Motivation `onConfigurationChange` in `ui/src/hooks/useConfiguration.ts` re-syncs the selected node through a 10 ms `setTimeout`, but that work is already done — correctly — by `useSelectionSync`. The `setTimeout` copy reads a **stale** node, so it is both redundant and slightly wrong. Split out from [#3589109](https://git.drupalcode.org/project/modeler/-/work_items/3589109). That issue fixed the same class of render-time staleness in `handleAutoLayout` and the viewport helpers ([!101](https://git.drupalcode.org/project/modeler/-/merge_requests/101)); this one was deliberately left out because it is not data loss and the right fix is a deletion rather than a patch. ### The code `ui/src/hooks/useConfiguration.ts:45-53`: ```ts // Update selected node to reflect changes in property panel if (selectedNode?.id === nodeId) { setTimeout(() => { const updatedNode = nodes.find(n => n.id === nodeId); if (updatedNode) { setSelectedNode(updatedNode); } }, 10); } ``` `nodes` here is the render-time snapshot taken at `:20`. The `setNodes(prev => ...)` call immediately above it updates the store, but `nodes` still points at the **pre-update** array for the rest of this tick. The 10 ms delay does not help: the closure captured the old array, so re-reading it later yields the same stale objects. The handler therefore pushes the *old* node object into `setSelectedNode`. ### Why it is already handled `useSelectionSync` (`ui/src/hooks/useSelectionSync.ts`, invoked at `ui/src/components/Flow.tsx:537`) does exactly this job, from fresh state, with an identity guard: ```ts useEffect(() => { if (selectedNode) { const updatedNode = nodes.find(n => n.id === selectedNode.id); if (updatedNode && updatedNode !== selectedNode) { setSelectedNode(updatedNode); } } // ... }, [nodes, edges, selectedNode, selectedEdge, setSelectedNode, setSelectedEdge]); ``` Because it runs in an effect keyed on `nodes`, it sees the post-update array and only writes when the reference actually changed. `ui/src/hooks/useConfigurationLoader.ts:181,198` already carries comments accommodating `useSelectionSync` updating the node reference, confirming it is the established mechanism. Net effect today: the `setTimeout` fires, briefly sets a stale node object, and `useSelectionSync` then corrects it. ## Proposed resolution Delete the `setTimeout` block. `useSelectionSync` covers the behavior from fresh state. Once removed, `selectedNode`, `setSelectedNode` and the `nodes` selector may all become unused in this hook — check each and remove what is genuinely dead, since ESLint's no-unused-vars will fail the build otherwise. Note that after [!101](https://git.drupalcode.org/project/modeler/-/merge_requests/101) `nodes` is used **only** by this block, so removing it would leave `useConfiguration` subscribing to no graph arrays at all — a welcome reduction in re-renders. ### Why not just make it read live state Reading `useGraphStore.getState()` inside the timeout would fix the staleness but keep a redundant, racy path that duplicates `useSelectionSync`. It would also re-introduce a real hazard: pushing an updated node object into the property panel *mid-edit* can reset debounced fields the user is currently typing into. Deleting is the safer end state. ## Remaining tasks - [ ] Remove the `setTimeout` block - [ ] Remove whichever of `selectedNode` / `setSelectedNode` / `nodes` become unused - [ ] Confirm the property panel still updates on configuration change (there is existing coverage in `ui/src/hooks/__tests__/useSelectionSync.test.ts`) - [ ] Confirm no regression in the debounced-field editing path ## User interface changes None intended — the selected node should continue to refresh in the property panel, via `useSelectionSync` alone. --- Note: this issue was drafted by an AI agent, which verified every line reference above against `1.0.x` at `1d04d40`.