Circular reference detected for service "s3fsfileservice" with mime_type guesser

Please provide the details of the module that provides the 'file.mime_type.guesser.http' service.

The circular reference part is understandable however without knowing why another mime type guesser is calling back to the file_system service it is hard to judge what possible solutions can be.

The s3fsfileservice currently needs the mime type guesser to allow it to determine mime types on upload during copy() and move() operations,

Just a reminder that I am willing to look deeper into this issue, however I still need additional information on what module is providing the 'file.mime_type.guesser.http' service.

Should I not hear back in a week (two weeks of inactivity) I will move this issue to could not reproduce.

Adjusting title of issue to better capture the root error.

I am unable to properly investigate this issue without knowing the other module involved.

It has been 2 weeks since this information was requested, therefore I am closing this issue as could not reproduce.

If you are able to provide more information in the future please re-open this issue and provide the name of the other module that is involved with this conflict.

Note: A search for file.mime_type.guesser.http in your site code may allow you to locate this service.

We currently are incompatible with the remote_stream_wrapper(RSW) module due to the fact it breaks http/https handling see #2902584: Incompatible with Remote Stream Wrapper module (maybe it is time to put a conflicts in on it since they haven’t worked on the linked issue)

However this is a new development that didn’t exist when we first looked into that module conflicting so I want to research to see if we might have problems with other modules in the future.

Even if we provided a fix for this you still need to uninstall RSW to use s3fs until they fix the issue of intercepting all connection

Note: RSW went unsupported due to an unresolved security issues last week and the Drupal security team advices not using the module at this time.

Well.... I'm not really sure how to approach the underlying issue this reveals exists.

I added the file_system decorator service to allow the s3fs module to more efficiently work with files (reduced IOPS and reduced local disk usage)

remote_stream_wrapper injects the file_system service so that it may call back in one location to thebasename()method and check if the file actually has an extension before calling the core extension guesser. This call to be somewhat redundant and can be removed. However removing the dependency from remote_stream_wrapper really is just 'kicking the can down the road' and hiding the eventual risk of this issue returning.

The core extension guesser calls back to the file_system service as well but it does it via a \Drupal::service() call which was added for D8.7 when deprecating drupal_basename().

This means the remote_stream_wrapper module is following the lead of core in using the service, and is following best practices by injecting the service rather than calling it globally.

However it feels appropriate to me that a file_system service decorator should be permitted to call the MimeTypeGuesser service since this is where file operations occurs.

I could see it being argued that these systems should just only deal with raw bytes of data and not care about the mimetype, however for s3fs that isn't an option, we need to know the mimetype at upload time and by removing the service were just moving it to a different class for the mimetype check.

Because core uses the file_system service this may pop up again from other streamWrapper modules.

Getting the following:

  Circular reference detected for service "s3fsfileservice", path: "plugin.cache_clearer -> plugin.manager.archiver -> s3fsfileservice -> file.mime_type.guesser -> drupal.proxy_original_service.file.mime_type.guesser.extension".

I traced it to the sophron_guesser module, a sub-module of Sophron
https://www.drupal.org/project/sophron

Sophron is a required module of ImageMagick
https://www.drupal.org/project/imagemagick

However, Sophron Guesser is an optional module.

Override Drupal core MIME type guessing
The Sophron module by itself just provides a service and an API for MIME type management. You can enable the complimentary Sophron guesser module to let Sophron manage the MIME type guessing, overriding Drupal core's guesser.

Edit: disabling sophron_guesser fixes the issue for us.

@jimconte Funny timing, I was mentioning last night that during a Slack discussion about ideas for how to address this issue that Sophron was broken as well. I'm quite amazed we haven't reports on both RSW and Sophron sooner.

Leading contender right now is to duplicate the file.mime_type.guesser and file.mime_type.guesser.extension services so that s3fs can have its own (replaceable) mime guessing service to call. This does mean that modules like Sophron (or a small shim module linking to Sophron) would need to provide guessers that do not use the file_system service as an injected service and register them independently of the core service. Since this new service would be the exact same API it would be minimal effort to implement for sites that need more than just the core extension guesser.

Lets give this a try.

New service s3fs.mime_type_guesser which does the same file.mime_type.guesser, and s3fs.mime_type.guesser which is the same as file.mime_type.guesser.

New service tag s3fs_mime_type_guesser to be used for discovering s3fs compatible mime type guessers.

Swapped in our new service for core's services. Copied test from core.

Our only risk is if core changes the constructors on the services we will need a patch (similar to what happened recently with D9.3.0 release) however these have been very stable for a while.

Adjusting title since we know this occurs with other modules.

Minor change to the patch (only in a test file) to allow testing against D8.9. This will show a deprecation message in D9.0+ however we can pick it up in the 4.x branch to switch this over to protected.

We don't have DrupalCi to test against 8.9 however local lab shows it good so I'm happy with this.

Anyone have any objections to this implementation method?

Looks pretty solid to me.