A parte complicada disso foi a recusa teimosa do navegador em revelar qualquer forma de mensagem de erro. Quando isso acontece, gosto de ir para a linha de comando e tentar, eliminando assim o servidor web como variável.

No bate-papo, descobrimos que a linha de comando mostrava o erro conforme o esperado, mas não o fez normalmente:o erro foi gerado e o script foi interrompido. Essa é uma falha difícil, não atribuível ao servidor da web.

Com a introdução de \Throwable , os cenários em que o PHP morre com dificuldade estão se tornando cada vez menos e mais distantes. Então, em um esforço para recuperar o fôlego do PHP, implementamos uma register_shutdown_function que puxou error_get_last em um esforço para descobrir o que, se alguma coisa, foi dito antes de explodir.

Isso revelou, brevemente, a mensagem de erro no navegador (desta vez usando um navegador diferente). No entanto, isso não foi repetível. O insight neste momento estava em cache:composer dump-autoload resolveu o problema!

Eu suspeito que o que aconteceu é isso:

• Eloquent lançou uma exceção
• PHP estava borbulhando isso através das classes de manipulação de exceção do Laravel
• Em algum momento, o PHP tentou carregar uma classe que não estava no autoloader
• PHP travou com força (este é um daqueles casos em que o PHP 7.0 falha)

Ao executar o composer dump-autoload , todas as classes "ausentes" foram trazidas para o alcance do autoloader e, quando tentado novamente, a sequência de código correta aconteceu.