Entity aliases are created before replication is complete.

1. +++ b/src/EventSubscriber/ReplicationFinished.php
   @@ -0,0 +1,102 @@
   +      $definitions = $this->aliasTypeManager->getVisibleDefinitions();
   +      foreach ($definitions as $id => $definition) {
   +        $entity_type = array_keys($definition['context'])[0];
   +        $this->updateEntitiesAlias($entity_type);
   +      }
   

   Usage of array_keys and accessing element in array by index is very sensitive to any change and can be broken easily
   Suggestion:

       $definitions = $this->aliasTypeManager->getVisibleDefinitions();
       foreach ($definitions as ['context' => $context]) {
         foreach ($context as $entity_type => $context_definition) {
           $this->updateEntitiesAlias($entity_type);
         }
       }
   

2. +++ b/src/EventSubscriber/ReplicationFinished.php
   @@ -0,0 +1,102 @@
   +    $ids = \Drupal::entityQuery($entity_type)->execute();
   +
   +    $storage = $this->entityTypeManager->getStorage($entity_type);
   

   Don't use \Drupal:: in OOP
   Suggestion:

       $ids = $this->entityTypeManager->getStorage($entity_type)->getQuery('AND')->execute();
       $storage = $this->entityTypeManager->getStorage($entity_type);
   

The failing tests points to the issue.

+++ b/src/EventSubscriber/ReplicationFinished.php
@@ -0,0 +1,103 @@
+  public function __construct(EntityTypeManagerInterface $entity_type_manager, ?AliasTypeManager $alias_type_manager, ?PathautoGeneratorInterface $path_auto_generator) {

I don't think there is an issue, it's just that coding standards does not support nullable types.

@l0ke I tend to not accept new PHP features until they will be fully supported by core and tests on d.o pass.

This needs tests.

https://www.drupal.org/docs/8/creating-custom-modules/let-drupal-8-know-...

Note that you need to have the test_dependencies change committed to your Git repository before you try to run a test that depends on it -- you cannot just put the info.yml change into the same patch as the new test.

test_dependencies:
  - pathauto:pathauto

We need to add test_dependencies to run our test properly but as the quote above says it cannot be done in a single patch.
I'd like to ask for your opinion what is the best scenario here?

And I also noticed that there is another issue with dispatching events #2971926: Better dispatch events we need to align with.

+++ b/src/Event/WorkspaceReplicationFinishedEvent.php
@@ -0,0 +1,45 @@
+class WorkspaceReplicationFinishedEvent extends Event {
...
+  protected $replication;

In my opinion it is better to store full $replication entity in event not just $source and $target to give as much context as we can.

Regarding the test dependencies, I faced this before and the fix is simple, as the documentation says, we need to add the test dependence in a separate patch and commit that one first.

I agree that using the replication object in the event is better.

I've updated the issue summary. Patches will follow-up soon.

@axicdv Relaxed and Workspaces are two modules that implement totally different concepts, Relaxed provides an extension for the core REST API and Workspace makes possible to group content together (on workspaces). While Relaxed depends on Workspace, the second one should work independently of the first one (as it is now). Making Relaxed a dependence for Workspaces is not correct, it shouldn't be there neither as a test dependence.

As I see from the patch, if you need to use the Relaxed events then your patch should go into Relaxed, not into Workspace. If you still need to fix aliases for internal replication too, then there should be implemented a fix in Workspaces without using Relaxed.

#2971926: Better dispatch events needs to be commited first.

I think all points were sorted out, the current case is covered with a new test and all tests are passing.

Thank you!

Changes required to issue #3016386: Allow to switch into an unpublished workspace

@spheresh Why do you upload a patch that has been already committed and the issue fixed? First it won't apply and second the issue has been fixed, open a new issue if needed.

@jeqq I just should apply this path to @beta18 version of the module. I know that life is much better when you are a maintainer, but I have to live in a world where you need to solve the composer.json requirements. Thank you for remarks, I'll create a new issue.

@spheresh The purpose of my remark is for respecting the best practices and your perception about us living in different worlds is wrong.

I respect your work and at the same time I have to be responsible for what people post here. In your case, the change you added to that patch is totally non relevant to this issue and it should live in another patch, in another d.o issue. Even if it would be relevant - in that case is created a follow-up issue if the current one is already fixed.