A loja em production devolve “There has been an error processing your request” e, embaixo, um Error log record number com 64 caracteres em hexadecimal. Isso não é protocolo de suporte: é o nome de um arquivo dentro de var/report/, na raiz do Magento, com o stack trace inteiro.
Abrir o relatório pelo ID
Entre na raiz do projeto e leia o arquivo com o mesmo hash que apareceu na tela. Nas 2.4.x o conteúdo é JSON em uma linha só, então passe pelo json.tool antes:
cd /var/www/loja
python3 -m json.tool var/report/c3489d113804c0d246c86c6923b238149a66f211f92920193d755646444a869c
# não copiou o hash da tela? pega o relatório mais recente
ls -lt var/report/ | head -5As chaves 0 e 1 trazem a mensagem da exception e o stack trace; junto vêm url, script_name e o próprio report_id. O módulo culpado quase nunca está na primeira linha do trace, porque as de cima são framework. Desça até achar um caminho em vendor/ ou app/code/ que não seja Magento_Framework.
O mesmo hash está no exception.log
O ExceptionHandler grava o report_id no contexto do log. Um grep pelos primeiros caracteres já te dá data, hora e mensagem sem abrir o JSON, e serve pra casar com o horário em que o cliente reclamou:
grep c3489d11 var/log/exception.log | head -2Quando var/report parece vazio
Duas causas. Se a pasta existe e não tem nada, o usuário do PHP-FPM não consegue escrever ali: confira com ls -ld var/report e devolva o dono. Se só aquele arquivo some, procure nos subdiretórios, porque com MAGE_ERROR_REPORT_DIR_NESTING_LEVEL (ou dir_nesting_level no pub/errors/local.xml) o Magento espalha os relatórios em pastas de dois caracteres:
find var/report -name 'c3489d11*'E resista a copiar pub/errors/local.xml.sample para local.xml numa loja aberta ao público: com <action>print</action> a mensagem real, com caminho de servidor e trecho de query, passa a aparecer pro visitante.
Se travou nisso e precisa de ajuda, me chama aqui.