Cache Magento 2.2.x desativado automaticamente

Primeiro, não consegui encontrar nenhuma informação sobre esse tipo de problema em nenhum lugar da Web.

Temos um ambiente de produção com integração com o git . Puxamos nossas alterações apenas através do git ( git pull ).

O problema é que, de alguma forma, em uma das etapas do Magento, os caches são desativados automaticamente (todos os zeros ao verificar o cache: status) . Isso causa um problema se isso for esquecido pelo programador, causando ainda mais sobrecarga no servidor devido ao alto tráfego 'batendo' no Magento sem cache.

Talvez alguns de vocês já tenham visto esse problema antes? Não sabemos quando ou como isso acontece exatamente.
E meio que aparece aleatoriamente.

Etapas comuns que fazemos:

• permitindo manutenção
• puxão
• instalação do compositor (se necessário)
• módulo ativar Vendor_ModuleName (se necessário)
• setup: upgrade (se necessário)
• limpando coisas estáticas
• comando de implantação
• limpando caches
• limpando opcache
• desativando a manutenção

Eu gostaria de receber sugestões valiosas que possam ajudar a resolver esse tipo de problema.

Parece um problema conhecido :
isso acontece de tempos em tempos no projeto em que estou trabalhando, mas não consegui encontrar as etapas para reproduzir. Tudo o que posso dizer é que isso acontece durante um processo de implantação.
Tudo o que pude encontrar é que, sob certas circunstâncias, um arquivo .regenerateé gravado na varpasta (na atualização da instalação ou na instalação / atualização do compositor) e se esse arquivo estiver presente durante a execução, setup:di:compileo cache será desativado e reativado quando o processo de compilação for concluído.
Por algum motivo, às vezes o cache não é reativado.
Adotamos a abordagem rápida e suja e fizemos a última etapa do processo de implantação php bin/magento cache:enablepara ter certeza. Então, basicamente escondemos a sujeira debaixo do tapete.

Você pode encontrar o código que desativa o cache aqui.
Ele está envolvido em uma TODO: removeinstrução.

Para quem estiver interessado, acho que posso trazer alguma luz sobre esse problema. Parece ser um problema de simultaneidade (condição de corrida) em \ Magento \ Framework \ Code \ GeneratedFiles :: cleanGeneratedFiles, quando o sinalizador var / .regenerate está definido e mais de um processo / solicitação tenta limpar os arquivos gerados .

É mais provável que isso aconteça quando você tiver o cron ativado e muitos grupos de cron usando use_separate_process config. Quando mais de um processo está tentando limpar o mesmo, o FileIterator falha com mensagens diferentes semelhantes 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.

Mover a chamada para $this->write->delete(self::REGENERATE_FLAG);, logo após a verificação da existência do sinalizador, resolve o problema, pois o primeiro processo que chega chega a ser responsável pela limpeza de arquivos.

Deixo aqui um vídeo de demonstração sobre como replicar o problema : https://youtu.be/9-X1cIIY7y8

E o script usado para isso:

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