Magento 2.2.x caché deshabilitado automáticamente

En primer lugar, no pude encontrar ninguna información sobre este tipo de problema en ninguna parte de la web.

Tenemos un entorno de producción con integración git . Extraemos nuestros cambios solo a través de git ( git pull ).

El problema es que, de alguna manera, en uno de los pasos, los cachés de Magento se desactivan automáticamente (todos los ceros al verificar el caché: estado) . Eso causa un problema si esto se pierde a través del programador, lo que provoca una sobrecarga del servidor debido al alto tráfico de Magento sin caché.

Tal vez algunos de ustedes han visto este problema antes? No sabemos cuándo ni cómo sucede exactamente.
Y aparece un poco al azar.

Pasos habituales que hacemos:

• permitiendo el mantenimiento
• git pull
• instalación del compositor (si es necesario)
• habilite el módulo Vendor_ModuleName (si es necesario)
• configuración: actualización (si es necesario)
• limpiar cosas estáticas
• comando de despliegue
• limpiar cachés
• limpieza de opcache
• deshabilitar el mantenimiento

Agradecería cualquier sugerencia valiosa que pueda ayudar a resolver este tipo de problema.

Esto parece un problema conocido :
esto sucede de vez en cuando en el proyecto en el que estoy trabajando, pero no pude encontrar los pasos para reproducirlo. Todo lo que puedo decir es que sucede durante un proceso de implementación.
Todo lo que pude encontrar es que, bajo ciertas circunstancias, .regeneratese escribe un archivo en la varcarpeta (ya sea en la actualización de la instalación o en la instalación / actualización del compositor) y si ese archivo está presente al ejecutar setup:di:compileel caché, se deshabilita y se vuelve a habilitar cuando finaliza el proceso de compilación.
Por alguna razón, a veces el caché no se vuelve a habilitar.
Tomamos el enfoque rápido y sucio e hicimos el último paso del proceso de implementación php bin/magento cache:enablepara estar seguros. Básicamente, escondimos la suciedad debajo de la alfombra.

Puede encontrar el código que deshabilita el caché aquí.
Está envuelto en una TODO: removedeclaración.

Para cualquier persona interesada, creo que puedo aportar algo de luz sobre este tema. Parece ser un problema de concurrencia (condición de carrera) en \ Magento \ Framework \ Code \ GeneratedFiles :: cleanGeneratedFiles, cuando se establece el indicador var / .regenerate y más de un proceso / solicitud intenta limpiar los archivos generados .

Es más probable que suceda cuando tiene habilitado cron, y muchos grupos cron usan use_separate_process config. Cuando más de un proceso intenta limpiar el mismo, FileIterator falla con diferentes mensajes similares a: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.

Subir la llamada a $this->write->delete(self::REGENERATE_FLAG);, justo después de marcar la verificación de existencia, resuelve el problema, ya que el primer proceso que llega se marca como responsable de limpiar los archivos.

Dejo aquí un video de demostración sobre cómo replicar el problema : https://youtu.be/9-X1cIIY7y8

Y el guión utilizado para ello:

#!/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"