Added a cache-clear to BLT to ensure memcache/db discrepancies do not…

[aweingarten]

When config split is used to enable DBlog in a lower env and you sync a Db from prod down on Acquia. Memcache will think that DBLog is enabled immediately after a DB sync. This will lead to CMI import failures as module enables will attempt to log to the nonexistent watchdog table.

A CC before a config import will solve the issue.

[dpagini]

Just pointing out, this is something that I see get added and removed from BLT on a cycle...

see #3166 for an example...

It would probably be beneficial to write some kind of test for these scenarios so it doesn't keep getting removed and re-added, but I'm sure that's not easy.

[lcatlett]

Just pointing out, this is something that I see get added and removed from BLT on a cycle...

see #3166 for an example...

It would probably be beneficial to write some kind of test for these scenarios so it doesn't keep getting removed and re-added, but I'm sure that's not easy.

to provide some context to the above comment, drush cr was removed because it was found to be the cause of sites losing context of their --root value when caches were rebuilding, which causes drush to fallback to its default site config and settings. On multisite this is often not an actual site on the project so attempting to import config in this case contributed to some very serious incidents on Site Factory. On acsf specifically, long running drush tasks are isolated to unique cache dirs to enable the Factory to execute said tasks concurrently.

I think the intent here is actually to dump the plugin, config, and service container when deploying code, but a cr alone wont accomplish this in many places since it may also depend on if a deploy_identifier is being used, zend opcache vs. usage. etc. @aweingarten and @dpagini do you think BLT is the appropriate project to address this, or should we advocate that drush, config_split, or another contrib project provide the needed functionality?

[mikemadison13]

i think this is something we do NOT want to introduce. there have been a lot of "to clear or not to clear" caches in various scenarios. i 100% understand this is an issue for you @aweingarten but i don't want BLT breaking deployments for a ton of other projects because we injected a new cache clear.

i'm open to discussing this if other people start reporting this issue, but thus far, yours is the only case that has cropped up.