Hi RF team,

We’re using the NodeResizer component with the shouldResize callback to prevent nodes from resizing beyond certain boundaries (also using nodeExtent for position limits). We’ve noticed that even when shouldResize returns false (thus preventing the resize), the onNodesChange event still fires with a "dimensions" change event that includes the rejected dimensions. This causes our internal React Flow state (node.measured.width/height) to become inconsistent with node.width/height, leading to rendering issues.

For clarity, when shouldResize returns false, the onResize callback is not triggered, which is expected. We rely on the onResize callback to update node.width and node.height in our Redux state (and then onNodesChange apply to RF nodes) so the diagram reflects the correct node size. However, onNodesChange still fires with the rejected dimensions and resizing = false. This results in the rejected width/height being applied to the React Flow node’s internal state (measured.width/height), causing size inconsistencies and incorrect UI.

Please see this recording (the nodeResizer is invisible, but you can see its boundary using the visible 4 handles)

There is also inconsistency comparing dragging and resizing behavior:

• When a node is dragged outside the boundary, the last event we receive with { dragging: false } correctly reports the last valid position

• But when resizing is rejected (shouldResize returns false), the last event with { resizing: false } does not reflect the last valid dimension — it reflects the attempted (but disallowed) dimension.

• Also, we noticed that onResizeEnd receives the same dimension as the final onNodesChange event, which seems to be a bug.

We currently filter out these rejected events by ignoring dimensions changes where resizing = false. However, this filtering feels inconsistent.

We wonder if this behavior is intentional, i.e., if onNodesChange is designed to emit all changes (including rejected ones) so that consumers can decide how to handle them? Or should events for prevented resizes ideally not be emitted at all?
If this is by designed, we should at least have the consistent behaviour between dragging and resizing event.

Please let me know you have any recommended approach to handle these "no-op" resize events consistently, or if this might be improved internally.

Thank you!