Errors when stream wrappers instantiate services in constructors because register() is called before container is built

A few other streamWrappers that appear to have same fault now:

https://www.drupal.org/project/media_avportal
https://www.drupal.org/project/gcsfs
https://www.drupal.org/project/rokka

These were all a simple "download module, install module", if it failed at that point with a similar stack it was considered to have the fault. No back validation performed on lower core versions.

Note: That depending how the installs fail they can leave the site in an unstable condition. The rokka module can't be uninstalled via the UI(isn't even accessible) or drush pmu due to multiple database table never created, even the drush cex; drush cim trick (where you remove the module from the core.extensions.yml) fails.

S3FS took down the entire test lab due to a thrown exception from a dependency library (missing default config, which in fairness we likely need to do something there to help mitigate) with no apparent way to recover the site.

The solution there was to make the classes lazy load their dependencies instead of injecting them. Is that an option here?

StreamWrappers don’t support injection (it’s not on the API spec in PHP itself) you have to call the global container.

Technically contrib could move the calls from the constructor to inline to try and delay the request to slightly latter however that create at least a couple concerns:

1. A streamWrapper needs to be able to start serving data immediately,
2. Not without being a potential API breach in the StreamWrapper class

Point one might look successful at first, howver the moment you add any code that triggers a read before the container is booted will cause abnormal issues or WSOD’s.

Point 2 is more about the fact streamWrapper classes may be API (depends on each contrib module, over in s3fs we do know our streamWrapper has been extended by others) and changing that is a major break, moving the error handling and failure points deeper into code that’s needs to be ready to respond at any time.

dependency injection led to circular dependency issues

We have fought that a few times in S3FS and are starting to learn it’s better to detangle the circle. Anything we did for that in being lazy or avoiding current known usages of circular dependency in the past eventually came back to bite us.

might fix this - could you test that MR against s3fs?

Technically speaking it now fails sooner due to a circular dependency error due to the first line of our constructor being:

  public function __construct() {
     $this->streamWrapperManager = \Drupal::service('stream_wrapper_manager');

For sake of testing I did comment out the circular call and the registration did proceed further, so in concept yes that patch helps however carries its own problems.

I see az_blob_fs and gcsfs appear they would be broken by that patch for same circular dependency flaw.
https://search.tresbien.tech/search?q=streamWrapperManager%20f%3A.tream....
(note, this search is limited assuming 'tream' is part of the file name, which is a bad assumption IMO however confirms at least two other impacted modules)

In s3fs we use StreamWrapperManagerInterface::normalizeUri() (not static) and a couple static methods(called on the instance). The statics I could solve by moving off the object instance, normalizeUri() would require duplicating code (and again possible API change for s3fs as would have to remove the property from our base stream Wrapper class)

Symfony\Component\DependencyInjection\Exception\ServiceCircularReferenceException: Circular reference detected for service "stream_wrapper_manager", path: "stream_wrapper_manager -> stream_wrapper_manager".

/var/www/html/vendor/symfony/dependency-injection/Container.php:214
/var/www/html/vendor/symfony/dependency-injection/Container.php:203
/var/www/html/vendor/symfony/dependency-injection/ContainerBuilder.php:598
/var/www/html/vendor/symfony/dependency-injection/ContainerBuilder.php:582
/var/www/html/web/core/lib/Drupal.php:203
/var/www/html/web/modules/custom/s3fs/src/StreamWrapper/S3fsStream.php:158
/var/www/html/vendor/symfony/dependency-injection/ContainerBuilder.php:1202
/var/www/html/vendor/symfony/dependency-injection/ContainerBuilder.php:637
/var/www/html/vendor/symfony/dependency-injection/ContainerBuilder.php:1320
/var/www/html/vendor/symfony/dependency-injection/ContainerBuilder.php:1265
/var/www/html/vendor/symfony/dependency-injection/ContainerBuilder.php:1276
/var/www/html/vendor/symfony/service-contracts/ServiceLocatorTrait.php:61
/var/www/html/vendor/symfony/dependency-injection/ServiceLocator.php:43
/var/www/html/web/core/lib/Drupal/Core/StreamWrapper/StreamWrapperManager.php:115
/var/www/html/web/core/lib/Drupal/Core/StreamWrapper/StreamWrapperManager.php:27
/var/www/html/vendor/symfony/dependency-injection/ContainerBuilder.php:1202
/var/www/html/vendor/symfony/dependency-injection/ContainerBuilder.php:637
/var/www/html/vendor/symfony/dependency-injection/ContainerBuilder.php:582
/var/www/html/web/core/lib/Drupal/Core/Test/TestRunnerKernel.php:74
...

Quick test of MR!16301 with s3fs and it does appear to allow tests to pass.

As an aside (not relevant to this issue, however worth Core team knowing from a design perspective):
I haven't been working on it it in some time haven't tested against 11.x at all, however in the s3fs 4.x series we would need to dynamically register streamWrappers, we couldn't expect them to be previously defined from a static list that would just be altered (as we do in the 3.x branch).

I'm not intendeding to imply any of these linked issues would actually break anything for us in 4.x I just want to encourage Core to keep in mind how early they bring streamWrappers in (ensure first compiler pass has always fully complete before the stream_wrapper_manager service is initialized). We have had to defend against core switching to service closures in the past cause issues with previously working code when the closure container differs from the final container.

For #13 (off topic to initial issue):
Yes a service provider, https://git.drupalcode.org/project/s3fs/-/blob/ef7d09953f5380b83ea1aa197...

Flysystem also does similar https://git.drupalcode.org/project/flysystem/-/blob/bc56a1f089f7a60f336e... (and theirs is in a stable release).

For context:
https://git.drupalcode.org/project/s3fs/-/commit/ef7d09953f5380b83ea1aa1... was the previous incident where service locators (closure with reduced container size) caused us issues (we were a second compiler pass to give us better access to Drupal Core services to load config).

I never raised that as a core issue as 4.x was/is pre-alpha and we found a workaround however from a design standpoint the latter a streamWrapper can register itself into the container the more UX and DX friendly it can be (and ideally everything during all the compiler passes is avoiding any stream access and is only working with raw files meaning late enrollment in container is a non-issue).