Revert: [rd] IJPL-171239: Wait until the ProjectEntity becomes visible in the current coroutine scope

GitOrigin-RevId: 99412ecc5d55697538884321815f58ddbb9047f7

platform/project/backend/src/BackendProjectEntitiesStorage.kt

@@ -16,9 +16,33 @@ import fleet.kernel.transactor
 internal class BackendProjectEntitiesStorage : ProjectEntitiesStorage() {
   override suspend fun createEntityImpl(project: Project) {
     val projectId = project.projectId()
+    //change {
+    //  shared {
+    //    ProjectEntity.new {
+    //      it[ProjectEntity.ProjectIdValue] = projectId
+    //    }
+    //  }
+    //}
+
+    // migrate to the implementation above when IJPL-172500 is investigated and a fix has been found
     change {
       shared {
-        ProjectEntity.new {
+        /*
+        This check is added to ensure that only one ProjectEntity is going to be created in split mode.
+        Two entities are possible due to a different flow in creating a project in split mode.
+
+        First, a project is created on the backend (ProjectEntity is created at the same time).
+        Then a signal about project creation is sent to the frontend via RD protocol.
+        At the same time, the shared part of Rhizome DB (where ProjectEntity is stored) sends the changes to the frontend.
+
+        Events which are coming via RD protocol are not synced with events coming via Rhizome DB.
+        So it can happen that while on the backend the signal is sent strictly after ProjectEntity creation,
+        on the frontend the signal can be received before there is ProjectEntity available in DB.
+
+        If it happens that the entity has not been found and the frontend creates a new one, Rhizome DB will perform a "rebase"
+        which basically re-invokes the whole "change" block either on the backend or the frontend side.
+        */
+        ProjectEntity.upsert(ProjectEntity.ProjectIdValue, projectId) {
           it[ProjectEntity.ProjectIdValue] = projectId
         }
       }