Uninstall breaks site

I haven't been able to duplicate this during the uninstall step yet, it looks like this will be depend upon having the force_password_change module installed.

Drupal\s3fs\StreamWrapper\S3fsStream->__construct() (Line: 262)
Drupal\Component\DependencyInjection\Container->createService(Array, 'stream_wrapper.public') (Line: 176)
Drupal\Component\DependencyInjection\Container->get('stream_wrapper.public', 1) (Line: 50)
Drupal\webprofiler\DependencyInjection\TraceableContainer->get('stream_wrapper.public') (Line: 131)
Drupal\Core\StreamWrapper\StreamWrapperManager->getWrapper('public', 'public://') (Line: 96)
Drupal\Core\StreamWrapper\StreamWrapperManager->getViaScheme('public') (Line: 47)

From this snippet we can gather that $settings['s3fs.use_s3_for_public'] = TRUE; was set in settings.php at the time of uninstall (or that the service container had not been refreshed after removing)

In #3061878: Uninstall does not allow reversion to local file system I touch on the fact that normally I (as a sysadmin) would anticipate that admins have fully migrated off s3fs before they try an uninstall it and this issue is somewhat in the same spirit. If s3fs is still handling public:// file streams when it is uninstalled Drupal core is expecting to use s3fs and if in the middle of an uninstall that ability is taken out from Drupal the results are undefinable.

Symfony\Component\HttpKernel\HttpKernel->handle(Object, 1, 1) (Line: 42)
Drupal\force_password_change\Service\ForcePasswordChangeRedirectMiddleware->handle(Object, 1, 1) (Line: 58)
Drupal\Core\StackMiddleware\Session->handle(Object, 1, 1) (Line: 48)

Best I can speculate is that force_password_change does something with the filesystem in the same request(or serialized into the cache) and that action is retained through the uninstall where the service container hasn't yet done a refresh to determine that s3fs is no longer available. This isn't intended to imply force_password_change is doing anything wrong, it is only intended to mean that it takes a perfect combination of another third party module utilizing the filesystem in middleware and not having fully decommissioned the s3fs module before uninstalling it.

Considering this doesn't appear to happen in a stock Drupal and it requires having not fully decommissioned the s3fs module before uninstalling I'm leaning towards this being either works as designed or won't fix unless someone can think of some step that can solve this easily.

About the only change I can think of at the moment is perhaps we can throw an exception during hook_uninstall however I'm not sure that is any better than the situation as it exists right now, both are WSOD's.

But uninstalling module through UI doesn't cause issue. But uninstalling through drush does.

Good to know, so this issue may be even more isolated and unlikely to occur.

I'm starting to be inclined to think at most this is a documentation addition.

I did discover uninstall validators but background reading it appears they were intended for content entities instead of situations like this. Additionally since s3fs is bootstrapped in at such a low level in Drupal I'm hesitant to make it harder to remove.

In line with #4 I've attached a draft for addition to the README providing some initial documentation on requirements to safely remove the s3fs module.

Just documenting will not prevent the issues reported in this issue from reoccurring, however I do not believe the s3fs module can every be safely uninstalled without proper planning and consideration about how it has been utilized in a deployment and the future steps that will be taken to replace it.

With no objections raised to suggested documentation I've merged it into Dev.

This doesn't hard prevent this from occurring in the future, but will provide a bit of background information for administrators to consider before uninstalling the module.