✨ [Frontend] Feature: sync with projectDocument:updated WS

[odeimaiz]

What do these changes do?

This PR implements the 1st iteration on the WebSocket synchronization for the projectDocument:updated event to enable Real Time Collaboration features.

1. Client 1 makes a change in its pipeline
2. This not-so-atomic change -PATCH (actually jsondiffpatch's deltas) is sent to the backend (the jsonPATCH is also calculated but not transmitted, this might come in the future)
3. The backend applies the patch and broadcasts that whole project document together with a version number to all the clients in the room
4. The frontend (if the patch was generated by itself (clientSessionId) or the version number is lower than the current, it will discard it) compares the project document with its current project. It will compute the deltas, convert those deltas into proper jsonPATCHES and apply them

Notes:

• In order to compare the project in projectDocument:updated and frontend's project, both objects need to be curated
• This patches need to be sorted so that they are applied carefully:
  • If a node was deleted, it will be the first patch to apply
  • Then the new nodes (not implemented yet)
  • And last, the updates to currently existing elements
• In order to avoid echo loops, while the patches from client1 are applied, the updates from client2 are blocked

Missing actions to sync, in order to avoid corrupted studies, userB will be logged out.

• add node
• change inputsRequired

Bonus:

• Upgraded jsondiffpatch library to its latest version. Own build to include the delta-to-jsonPATCH (RFC 6902) formatter.
• Adds client session ID tracking to HTTP headers for better conflict detection

Study changes:

Workbench changes and Run pipeline:

Dynamic service:

Study UI changes:

Related issue/s

• related to Simultaneous access to a pipeline in view-only mode (Aug.) osparc-issues#1647
• related to ✨ Is1647/collaboration feature - 1. iteration (OPS ⚠️) #8140

How to test

Dev-ops

[Copilot]

Pull Request Overview

This PR implements the first iteration of WebSocket synchronization for projectDocument:updated events to enable real-time collaboration features. The implementation allows multiple clients to synchronize pipeline changes through WebSocket broadcasts, with conflict detection and automatic patch application.

• Adds WebSocket listener for projectDocument:updated events with conflict detection via client session ID
• Implements JSON patch-based synchronization using upgraded jsondiffpatch library (v0.7.3)
• Adds support for real-time UI updates including node positions, annotations, and edges

Reviewed Changes

Copilot reviewed 14 out of 15 changed files in this pull request and generated 6 comments.

Show a summary per file

File	Description
JsonDiffPatch.js	Upgrades library to v0.7.3 and adds delta-to-JSON patch conversion
StudyEditor.js	Implements WebSocket project document synchronization and patch application
Workbench.js	Adds support for updating workbench from JSON patches
StudyUI.js	Implements UI patch handling for annotations and node UI changes
Study.js	Adds study-level patch handling methods
Node.js	Adds node-level patch application and position change events
WorkbenchUI.js	Adds edge creation/removal event handling and annotation listeners
NodeUI.js	Adds position change listener for real-time updates
Resource.js	Adds client session ID to HTTP headers
Various other files	Minor fixes and improvements for robustness

[matusdrobuliak66]

💪

[GitHK]

• In order to avoid echo loops, while the patches from client1 are applied, the updates from client2 are blocked

What does this refer to? From what I've seen in a PR from @matusdrobuliak66 this should not be possible. Can you please clarify this part

[odeimaiz]

• In order to avoid echo loops, while the patches from client1 are applied, the updates from client2 are blocked

What does this refer to? From what I've seen in a PR from @matusdrobuliak66 this should not be possible. Can you please clarify this part

In our case, avoiding an echo loop means preventing client B from re-sending to the backend the changes it just applied from client A, since the backend already has those.

There are more ways to avoid this useless patches, but with the current approach of the frontend not sending granular patches and the backend broadcasting the entire project document, I find this is the safest solution.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[GitHK]

• In order to avoid echo loops, while the patches from client1 are applied, the updates from client2 are blocked

What does this refer to? From what I've seen in a PR from @matusdrobuliak66 this should not be possible. Can you please clarify this part

In our case, avoiding an echo loop means preventing client B from re-sending to the backend the changes it just applied from client A, since the backend already has those.

There are more ways to avoid this useless patches, but with the current approach of the frontend not sending granular patches and the backend broadcasting the entire project document, I find this is the safest solution.

Think I got it, the backend keeps track of the latest version, but nothing stops the frontend from sending the same data as a new update, which could even be a legitimate use case.

[GitHK]

Thanks, and I've noticed how you "cheated" with the jupyter!

[sanderegg]

nice!