Contrib.social

Possible conflict between Cloudflare and Redis cache causing WSOD on every Symfony request after update from beta2 to beta3

Open on Drupal.org →
Created on 20 March 2023, about 2 years ago

Hello all,

(Apologies in advance as I'm not entirely sure the root cause of this issue yet, but I wanted to outline a problem I've had the last couple of weeks trying to update our D9.5.x sites from Cloudflare beta2 to beta3.)

I manage 11 D9.5.x sites, two of which have the Drupal Cloudflare module enabled and connected to CF (i.e. the API keys are set, and the zone [domain] is also set), another 8 of which have the Cloudflare module enabled but not configured, and two which have the CF module in the codebase but it isn't enabled.

All sites use Redis persistent cache.

For the last three weeks we have been unable to update the two sites which use the CF module. As soon as we upgrade from beta2 to beta3 - which also updates from https://github.com/d8-contrib-modules/cloudflarephpsdk.git 1.0.0 to https://github.com/cloudflare/cloudflare-php.git 1.1.6 - and run drush updb, the site immediately returns an HTTP 500 error on every web request.

Because this was only occurring on our production sites, and we could not reproduce in QA or local, this has proven very difficult to fully diagnose as our number one priority was to restore the site - we had to revert to the old codebase and restore a database backup.

When this happened, we saw Watchdog filling with a single error for every request - in one failed deployment it was:

4015436 16/Mar 23:02 php Error InvalidArgumentException: The configuration property zone_id.0 doesn't exist. in Drupal\Core\Config\Schema\ArrayElement->get() (line 76 of /app/web/core/lib/Drupal/Core/Config/Schema/Array

In other failed deployments, we saw error messages such as:

Argument 1 passed to Drupal\Core\Routing\RequestContext::fromRequest() must be an instance of Symfony\Component\HttpFoundation\Request, null given, called in core/lib/Drupal/Core/Routing/RequestContext.php on line 36 and defined in Drupal\Core\Routing\RequestContext->fromRequest() (line 42 of core/lib/Drupal/Core/Routing/RequestContext.php).

In two such failed deployments, Drush was also affected; in every other failed deployment, Drush ran normally and gave no indication there was a problem.

Disabling the Cloudflare module with drush pmu cloudflare before updating prevents this problem from occurring.

In digging in to this issue, one update which ran was cloudflare_update_8003.

The code for this update is:

/**
 * Cloudflare to support multiple zones for multiple domains.
 */
function cloudflare_update_8003(&$sandbox) {
  // Convert existing zone id value from type string to array.
  $config = \Drupal::service('config.factory')->getEditable('cloudflare.settings');
  $zone_id = $config->get('zone_id');
  $config->set('zone_id', $zone_id ? [$zone_id] : [])->save();
}

Could there be something in the way the Cloudflare code is written that means it isn't correctly checking whether cloudflare.settings.zone_id is a string|int or array?

I.e.: $config->set('zone_id', $zone_id ? [$zone_id] : [])->save();

Or, could it perhaps be the case that Redis persistent cache isn't gracefully handling the case where a configuration object changes its type from e.g. in this case a string|int to an array?

Thank you all for your time and any insight you might be able to offer on what's causing this.

Alex :)

🐛 Bug report
Status

Active

Version

2.0

Component

Code

Created by

🇬🇧United Kingdom alexharries

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

  • Issue created by @alexharries
  • Comment about 2 years ago →
    🇬🇧United Kingdom alexharries
  • Comment about 2 years ago →
    🇬🇧United Kingdom jrsouth

    Just chipping in because I've just hit what appears to be the same (or very similar) problem after a beta2 to beta3 upgrade. We have redis in our stack too.

    All requests coming via the site's default CloudFlare-cached route return the fromRequest() must be an instance 500 error, but a separate route to the same Drupal instance without CloudFlare caching works as expected.

    (I imagine it's simply that the non-cached traffic doesn't trigger the module code, and therefore doesn't raise the error, but thought it was worth noting that the site can successfully handle requests with the module active and configured.)

    For now I've disabled cloudflare and cloudflarepurger via drush, and the site is working normally via the default route ― though obviously I'd prefer to have those modules enabled!

    I'm in the very early stages of diagnosing this, will add more as I learn more.

  • Comment about 2 years ago →
    🇬🇧United Kingdom jrsouth

    For our site this seems to be directly related to "Restore Client IP" setting.

    Switching that option off (which is fine for our purposes, even desirable) resulted in a working site via the main route, proxied by Cloudflare.

    I'm therefore able to move on from this issue for now, but I'll keep an eye out, and am happy to help diagnose if there are any questions.

  • Comment almost 2 years ago →
    🇬🇧United Kingdom alexharries

    I can confirm this is a problem with "Restore client IP address".

    Will update the issue title and description accordingly.

  • Comment almost 2 years ago →
    🇬🇧United Kingdom alexharries
  • Comment 10 months ago →
    🇨🇦Canada brunodbo

    I ran into this as well. For anyone else hitting this, you can disable the "Restore Client IP Address" option with drush config:set cloudflare.settings client_ip_restore_enabled 0. That made requests cached by Cloudflare work again for me.

  • Comment 8 months ago →
    🇺🇸United States Albert Volkman

    Seeing this in the 2.0.x branch as well. Bumping up so we can fix it there first.

  • Comment 8 months ago →
    🇺🇸United States Albert Volkman

    This looks similar- https://www.drupal.org/project/drupal/issues/3243387 🐛 Argument 1 passed to Drupal\Core\Routing\RequestContext::fromRequest() must be an instance of Symfony\Component\HttpFoundation\Request, null given Closed: cannot reproduce

  • Comment 8 months ago →
    🇺🇸United States Albert Volkman
  • Comment 19 days ago →
    🇮🇪Ireland frankdesign

    Just wondering is anyone has figured this one out. I am seeing this issues with Drupal 10.4 and Cloudflare 2.0.0-beta1. As soon as I enable "Restore Client IP Address", the entire site goes down. The only way to resolve is to use Drush to uninstall the module.

contrib.social Blog FAQ Discussions
Production build 0.71.5 2024