If a module provides a subscriber for a kernel event, for example (\Symfony\Component\HttpKernel\KernelEvents::RESPONSE), and it gets uninstalled on the UI then the event dispatcher service still calls its event subscriber that could lead to errors.
Our module provides an MY_ENTITY_TYPE entity type and it has a KernelEvents::RESPONSE subscriber, my_module.event_subscriber.response. The event subscriber retrieves the entity storage of the MY_ENTITY_TYPE in its constructor. What happens when the module gets uninstalled on the UI? The \Drupal\Core\Extension\ModuleInstaller::uninstall() does a bunch of things, but most notably:
* uninstalls the MY_ENTITY_TYPE entity type
* calls the $this->updateKernel($module_filenames); - before that the my_module.event_subscriber.response service is still registered. If you run $container->get('event_dispatcher') at this point and check the registered listeners with xDebug you should see the my_module.event_subscriber.response is not registered anymore.
* after the ModuleInstaller::uninstall() finished the module is uninstalled.
* the reponse for the request is also ready so the HTTP Kernel triggers the KernelEvents::RESPONSE event.
* (surprise) the called instance of the event_dispatcher service in that context still contains the my_module.event_subscriber.response event subscriber as a registered listener so it gets called
* and the request silently fails with an exception in \Symfony\Component\HttpKernel\HttpKernel::handleException() because as I wrote the "The event subscriber retrieves the entity storage of the MY_ENTITY_TYPE in its constructor." but the entity type is not registered anymore.
After a module gets uninstalled Drupal core should not call its event subscriber (including kernel events). At least, I do not see any use case why an uninstalled module's event subscriber should be called after it has been uninstalled within the same page request.
Needs work
10.1 ✨
Not all content is available!
It's likely this issue predates Contrib.social: some issue and comment data are missing.
The issue still makes sense as when modules uninstalled via UI the remaining request processing still working with container which have services/listeners initialized. And overtime complexity of contrib is growing so it will hit early or later
OTOH agree with #39 about complexity and overhead it brings
A compromise could be to add some defensive code to core, at least to give a hand to contrib to deal with it