Update container namespaces reference instead of hard set

This simple test shows that the parameter is replaced with a new value instead of updating the existing instance.

+1

Maybe problem even not in a hard updated values. The hook config_translation_config_translation_info() from steps to reproduce gets EntityTypeManager from an updated container.

So the problem most likely in \Drupal\Core\DrupalKernel::updateModules. This method takes care of adding new namespaces, but it not removes the ones for uninstalled modules. This also leads to this problem, even if container.namespaces will be updated via an existing instance.

Basically, when you uninstall the module, updated container still pass namespace of this module to other services. 🤔

Added workaround: if container.namespces a service is already instantiated, we update this instance of an ArrayObject. In that case, all previously instantiated services will also hold an updated list of namespaces.

Added important note for steps to reproduce. The config entity should also define the edit-form link template. Because without it, the hook will skip that entity and bug won't be reproduced.

The last submitted patch, 5: core-3352166-5.patch, failed testing. View results →

The last submitted patch, 5: core-3352166-5-test-only.patch, failed testing. View results →

Hah, there is even a todo sounds like the problem I faced in \Drupal\config_translation\ConfigMapperManager::getDiscovery

      // @todo If the list of installed modules and themes is changed, new
      //   definitions are not picked up immediately and obsolete definitions
      //   are not removed, because the list of search directories is only
      //   compiled once in this constructor. The current code only works due to
      //   coincidence: The request that installs (for instance, a new theme)
      //   does not instantiate this plugin manager at the beginning of the
      //   request; when routes are being rebuilt at the end of the request,
      //   this service only happens to get instantiated with the updated list
      //   of installed themes.

So it's sounds like a different issue. I did testes with my fix with a problem project, and it doesn't help, than it's not about incorrect namespaces.

But still, it leads me to this topic. Should we update an instantiated array object with namespaces instead of pushing a new one? Because it still a problem for cases when this list is received and then container is rebuilt. All code who uses container.namespaces service will be affected by this problem. The tests actually shows it.

The last submitted patch, 5: core-3352166-5.patch, failed testing. View results →

The failures in #5 main patch seem legit.

I'm actually needing an advice here. The test for #5 requires test to be a Kernel one, but the DrupalKernel in HEAD is Unit. Switching it to Kernel causes failures in #5

1) Drupal\Tests\Core\DrupalKernel\DrupalKernelTest::testFindSitePath
Failed asserting that two strings are equal.
--- Expected
+++ Actual
@@ @@
-'sites/example'
+'sites/simpletest/47698822'

I'm actually not like the idea to switch DrupalKernelTest to Kernel just for a single check, but I'm not sure how to handle it in other way? So should I update DrupalKernelTest::testFindSitePath accordingly or better create another test file for Kernel DrupalKernel testing?

Would post to #contribute for help.

This fix seemed to cause this failures so there may be backwards compatibility concern now.