Uninstalling Feeds Tamper will result into feeds type getting deleted

Thanks for filing a bug report. It’s annoying Feeds Tamper cannot be safely uninstalled. I would need to take a deep dive in how configurations can get properly updated when wanting to uninstall a module that adds third party configuration (because that’s what Feeds Tamper does: it adds extra configuration on the feed type).

I just ran into a similar issue when attempting to uninstall Feeds Tamper. NOTE: I had already deleted the Feed Type that had used Feeds Tamper prior to uninstalling the module, so it isn't exactly the same situation, but I hope this report helps you figure out the larger issues around uninstalling safely.

I ran drush pm-uninstall and that worked as expected. I then ran composer remove and that also completed without error. But when I then attempted to run drush cr, I got the following errors:

PHP Fatal error:  Uncaught AssertionError: The file specified by the given app root, relative path and file name (/var/www/weta.test/web/modules/contrib/tamper/tamper.info.yml) do not exist. in /var/www/weta.test/web/core/lib/Drupal/Core/Extension/Extension.php:67
Stack trace:
#0 /var/www/weta.test/web/core/lib/Drupal/Core/Extension/Extension.php(67): assert(false, 'The file specif...')
#1 /var/www/weta.test/web/core/lib/Drupal/Core/Extension/ModuleHandler.php(114): Drupal\Core\Extension\Extension->__construct('/var/www/weta.t...', 'module', 'modules/contrib...', NULL)
#2 /var/www/weta.test/web/core/lib/Drupal/Component/DependencyInjection/Container.php(277): Drupal\Core\Extension\ModuleHandler->__construct('/var/www/weta.t...', Array, Object(Drupal\Core\Cache\ChainedFastBackend))
#3 /var/www/weta.test/web/core/lib/Drupal/Component/DependencyInjection/Container.php(173): Drupal\Component\DependencyInjection\Container->createService(Array, 'module_handler')
#4 /var/www/weta.test/web/core/lib/Drupal/Core/DrupalKernel.php(586): D in /var/www/weta.test/web/core/lib/Drupal/Core/Extension/Extension.php on line 67

Fatal error: Uncaught AssertionError: The file specified by the given app root, relative path and file name (/var/www/weta.test/web/modules/contrib/tamper/tamper.info.yml) do not exist. in /var/www/weta.test/web/core/lib/Drupal/Core/Extension/Extension.php:67
Stack trace:
#0 /var/www/weta.test/web/core/lib/Drupal/Core/Extension/Extension.php(67): assert(false, 'The file specif...')
#1 /var/www/weta.test/web/core/lib/Drupal/Core/Extension/ModuleHandler.php(114): Drupal\Core\Extension\Extension->__construct('/var/www/weta.t...', 'module', 'modules/contrib...', NULL)
#2 /var/www/weta.test/web/core/lib/Drupal/Component/DependencyInjection/Container.php(277): Drupal\Core\Extension\ModuleHandler->__construct('/var/www/weta.t...', Array, Object(Drupal\Core\Cache\ChainedFastBackend))
#3 /var/www/weta.test/web/core/lib/Drupal/Component/DependencyInjection/Container.php(173): Drupal\Component\DependencyInjection\Container->createService(Array, 'module_handler')
#4 /var/www/weta.test/web/core/lib/Drupal/Core/DrupalKernel.php(586): D in /var/www/weta.test/web/core/lib/Drupal/Core/Extension/Extension.php on line 67
 [warning] Drush command terminated abnormally.

Putting the module code back via composer require temporarily solved the problem, allowing me to determine that the issue was that core.extension within the config settings still included tamper: 0, suggesting it still expected the module to be there, even though it had been uninstalled (multiple times, by that point).

Deleting that line via drush config:edit allowed me to remove the module files without crashing my site.

I think I figured out what was going on with my uninstall. I had uninstalled feeds_tamper. I had not uninstalled tamper. A note to the user reminding them that they need to uninstall both modules before removing any code would probably avoid a lot of frustration.

+1 on original issue.

I experienced the same issue while working on #2907721: Log items that failed to import and I found out that it is actually a Feeds issue.

The cause of the issue is that FeedType::onDependencyRemoval() does not call its parent. ConfigEntityBase::onDependencyRemoval() cleans up third party settings from modules that are getting uninstalled.

A fix will follow.

It took me a long time to figure out why the test did not fail on the testbot, but not locally. I setup DrupalCI locally (see https://www.drupal.org/drupalorg/docs/drupal-ci/running-drupalci-locally) and after a long debug round I finally found a difference between my local setup and the testbot. The cache backend is different. The testbot apparently uses ChainedFastBackend which wraps around ApcuBackend while my local setup uses DatabaseBackend. At first, in the test only branch the feed type remained in the APCu cache after deleting it programmatically. Clearing the APCu cache using apcu_clear_cache() fixed that issue and made the test only branch finally fail on the testbot. Now I can ensure that the bug won't come back in the future.

Merged the code.