Cache Magento 2.2.x désactivé automatiquement

Tout d'abord, je n'ai trouvé aucune information sur ce type de problème sur le Web.

Nous avons un environnement de production avec intégration git . Nous ne tirons nos modifications que via git ( git pull ).

Le problème est que, d'une manière ou d'une autre, dans l'une des étapes, les caches Magento se désactivent automatiquement (tous les zéros lors de la vérification du cache: état) . Cela provoque un problème si cela est manqué via le programmateur, ce qui entraîne une surcharge du serveur en raison du trafic important vers le Magento sans cache.

Peut-être que certains d'entre vous ont déjà vu ce problème? Nous ne savons pas quand ni comment cela se produit exactement.
Et cela apparaît un peu au hasard.

Étapes habituelles que nous effectuons:

• permettre la maintenance
• git pull
• installation du compositeur (si nécessaire)
• module enable Vendor_ModuleName (si nécessaire)
• configuration: mise à niveau (si nécessaire)
• effacement des éléments statiques
• commande de déploiement
• effacement des caches
• effacer opcache
• désactivation de la maintenance

J'apprécierais toute suggestion utile qui pourrait aider à résoudre ce type de problème.

Cela ressemble à un problème connu :
cela se produit de temps en temps sur le projet sur lequel je travaille, mais je n'ai pas pu trouver les étapes à reproduire. Tout ce que je peux dire, c'est que cela se produit lors d'un processus de déploiement.
Tout ce que j'ai pu trouver, c'est que dans certaines circonstances, un fichier .regenerateest écrit dans le vardossier (lors de la mise à niveau de l'installation ou de l'installation / mise à niveau du compositeur) et si ce fichier est présent lors de l'exécution setup:di:compiledu cache est désactivé et réactivé lorsque le processus de compilation est terminé.
Pour une raison quelconque, le cache n'est parfois pas réactivé.
Nous avons adopté une approche rapide et sale et avons fait la dernière étape du processus de déploiement php bin/magento cache:enablepour être sûr. Donc, fondamentalement, nous avons caché la saleté sous le tapis.

Vous pouvez trouver le code qui désactive le cache ici
Il est encapsulé dans une TODO: removeinstruction.

Pour toute personne intéressée, je pense que je peux apporter un peu de lumière sur cette question. Il semble s'agir d'un problème de concurrence (condition de concurrence critique) dans \ Magento \ Framework \ Code \ GeneratedFiles :: cleanGeneratedFiles, lorsque l'indicateur var / .regenerate est défini et que plusieurs processus / demandes essaient de nettoyer les fichiers générés .

Il est plus probable que cela se produise lorsque cron est activé et que de nombreux groupes cron utilisent la configuration use_separate_process. Lorsque plusieurs processus tentent de nettoyer le même, FileIterator échoue avec différents messages similaires à:FilesystemIterator::__construct(/Users/adrianmartinez/Sites/r2-project-develop-b2b/environments/2-2-develop-b2b/magento/generated/code): failed to open dir: No such file or directory.

Passer à l'appel $this->write->delete(self::REGENERATE_FLAG);, juste après la vérification de l'existence d'un indicateur, résout le problème, car le premier processus arrivant se marque comme responsable du nettoyage des fichiers.

Je laisse ici une vidéo de démonstration sur la façon de reproduire le problème : https://youtu.be/9-X1cIIY7y8

Et le script utilisé pour cela:

#!/bin/bash

# \Magento\Framework\Code\GeneratedFiles has a concurrency problem
# Create regenerate flag and launch parallel commands that try to regenerate at the same time
# This is a real case, cron:run launches stand alone processes in parallel

# Created by magento composer installer upon code install or module enable/disable
touch var/.regenerate

# Launch parallel commands
# Error differs each execution, sometimes it even works
bin/magento cron:run --group=ddg_automation --bootstrap=standaloneProcessStarted=1 2>&1 &
bin/magento cron:run --group=index --bootstrap=standaloneProcessStarted=1 2>&1 &

wait
echo "All done"