UI update race conditions in Edit Constraint View

🐛 Bug Report

Summary

The Edit Constraint View allows users to search for data elements and properties. The current implementation uses debounced live input to trigger asynchronous search queries, followed by UI updates based on the returned results. Because each step is asynchronous and can overlap and lead to race conditions depending on the performance and speed of the client browser and the server performance. The race conditions may lead to inconsistent or conflicting DOM updates that don’t accurately reflect the user's current input.

Examples:

• The UI error of "No Descendants" is displayed twice.
• The UI error of "No Descendants" is displayed, but there is no actual error. The error belongs to another element based on the previous search.

Steps to Reproduce

Currently, I'm not reliable able to reproduce it. I assume that low performance of the client browser, bad connection to the server, and complex constraints exacerbate the problem.

What is the current bug behavior?

• Multiple asynchronous sequences run concurrently.
• UI updates from older searches may apply after newer ones, leading to flickering or inconsistent UI state.
• DOM elements may be added, removed, or animated out of sync with the current user input.

What is the expected correct behavior?

• Only the UI updates corresponding to the most recent valid search input should be applied.
• Previous or outdated sequences should be cancelled or ignored once a new input is detected.
• The UI state should be predictable and consistent with the current input.

Possible Fix or Suggested Solution

Refactor the async flow using XState (state machine approach):

• Model UI states explicitly (idle → debouncing → fetching → UI update → idle)
• Use invoke with onDone/onError to encapsulate and cancel async fetches + UI changes
• Automatically cancel ongoing actions when transitioning out of a state
• Prevent DOM race conditions by ensuring updates are only committed from the active state flow