Local without memcache breaks after update

The same happened for me when updating from 2.5 to 2.6.

memcache_admin_post_update_add_service_definitions invalidated the container, as intended, and afterwards local/development/whatever environments with this module enabled whilst having neither Memcache nor Memcached installed fail with a 500 Uncaught PHP Exception Drupal\memcache\MemcacheException: "No Memcache extension found".

The MR solved our use case (having drupal/memcache enabled, but neither Memcache nor Memcached installed), but is at best "iffy".

Not even sure how this situation came to be, since it seems to be not possible to enabled this module without having either Memcache or Memcached installed (See also #3136253: Disable memcache on local or dev environments (Drupal 8)), but here we are.

A "proper" solution would include decent tests, probably(?) a dedicated setting and the possibility to install without having either Memcache or Memcached installed.

But foremost, we need a blessing from the maintainer(s) if they want to support such a solution.

Putting this on NR in the hope this will attract that attention.

I had the same error one of our environments didn't have a good memecache compiled for its PHP. So you can also get to this situation if you had updated PHP in the past, but forgot to compile memecache the extension or choose not to.

BUT the patch did not fix it, so I think it needs work still, same error.

Another scenario is when using a service like TugboatQA which does not have memecache enabled.

Good catch. Committed!

Any chance getting a new release with this fix?

I was having the same issue and ended up tracking it down to this issue... I have a different symptom. After running composer update my `drush cr` failed with this message:

$ drush cr

In Container.php line 147:

Circular reference detected for service "module_handler", path: "module_handler -> cache.bootstrap -> logger.factory -> logger.syslog -> config.factory -> config.typed".

Failed to run drush cr: exit status 1

the `drush updb` succeeded but had some
[error] MemcachedDriver::set() error
errors.

I then put in a breakpoint where the exception was being thrown and traced it back to Memcache and reverted from 8.x-2.6 to 8.x-2.5 and the problem was resolved. Also updated to the latest dev release resolves the issue.

I am putting the specific errors I had in here to make it easier to find when searching.

Pushing for a full release of this fix. Our sites avoid dev versions as potentially unstable, and this is playing havoc with our testing pipeline and requiring significant workarounds for non-production environments.

I am also having a similar circular reference issue after upgrading to Drupal 10.3.1 and downgrading memcache to 2.5.0.

After running drush cr I get the following error:

In Container.php line 222:

Circular reference detected for service "cache.bootstrap", path: "module_handler -> cache.bootstrap -> cache.backend.memcache -> Drupal\Component\Datetime\TimeInterface -> state -> cache.bootstrap".

This is still an issue on the 2.7 release

Downgrading to 2.5 worked for me to fix. Not ideal obviously

Well shoot. Lets see if there are other reports and then re-escalate as a bug. I'll try to reproduce the issue, but it won't be until next week or early September though.

@paulsheldrake What are the symptoms of the issue on 2.7?

Any errors showing in the log, on screen, etc?

Circling back: the fix on 2.7 seems to work for me. Note that I did need to run drush updatedb which ran add_service_definitions from memcache_admin to clear an error that appeared.

EDIT: I was wrong. Still breaking on my staging environment. Looks like memcache was added locally because of this issue.

Issue I'm seeing is:

The website encountered an unexpected error. Please try again later.

Drupal\memcache\MemcacheException: No Memcache extension found in Drupal\memcache\Driver\MemcacheDriverFactory->initialize() (line 179 of modules/contrib/memcache/src/Driver/MemcacheDriverFactory.php).

Hmmm same here. I swear this fix worked initially, but now I am seeing the same error as #18 again in 8.x-2.7.

Ah, wait, I see -- in my local environment I have a config that is equivalent to:

$settings['memcache']['servers'] = [];
$settings['memcache']['bins'] = [];

But, I did not have that in a remote test environment I was looking at. Hence the confusion. The errors goes away when those settings values are set to empty arrays.

From the discussion it sounds like there is some history to this, but I wonder if there is any way to prevent this error without also requiring that config?

I'll second this - it should fail much more gracefully than it does. When I have time, I'll see if I can work up a patch for that.

As a data point, we are seeing this issue on 2.7 as well. Adding the lines in settings.local.php works for local but adding to environmental conditional statement in settings.php does not work on dev/staging server environments (Acquia). Running drush commands results in error "Memcache instance could not be initialized. Check memcache is running and reachable".

Reverting to 2.5 seems to be the only solve for now. Core 10.3.9

I switched back to 2.5 for drupal 10.4.1 and worked for me , waiting for a fix

same here. back to 2.5 for now

'drupal/memcache:2.x-dev@dev' still has the problem

Looks like a failing test on that MR - putting back to needs work.

A simple fix based on what has already been committed.

The reports since then the initial commit are a different situation: the opt-out was in settings.local.php but not on the staging, so those environments had the module enabled with neither a memcache extension/server nor the opt-out. #22's "Memcache instance could not be initialized" text comes from Acquia's memcache-settings include, not from this module. Those environments need the same two lines, or should not have the module enabled there (config_split etc.).

The changes to MR44 and 29 both make a *missing* setting mean "disabled". We don't want to do that:

• !44 returns from `initialize()` before the extension, driver class and default server are set. With the Memcached extension installed and no `servers` setting — the documented default — `get()` then fatals. That is the failing test in #28.
• Patch from #29 `==` makes `NULL == []` true, so a host where the extension is simply missing silently runs with memcache off instead of reporting it. A missing extension is a REQUIREMENT_ERROR (memcache.install:19-27); hiding it is the kind of silent failure #2305791 just removed. A missing setting deliberately means the default server.