Esconderam os erros do Moodle, e os plugins falhavam em loop

Caso real de produção, contado sem identificar o cliente. À primeira vista, aquele Moodle parecia saudável: nenhuma mensagem de erro na tela, tudo "limpo". Só que ele vivia lento e instável, sem explicação aparente. A explicação estava escondida: literalmente. Quem geria a plataforma antes tinha colocado código para ocultar os erros, forçando o Moodle a não exibir falha nenhuma. E, por baixo desse silêncio, plugins falhavam em loop, repetidamente, a cada ciclo.

Por que esconder o erro é o pior "conserto"

Desligar a exibição de erros não conserta nada: apenas tira o sintoma da vista. É trocar a luz de advertência do painel por uma fita preta: o carro continua com o mesmo problema, você só parou de vê-lo. No Moodle, o efeito é ainda pior, porque some justamente o sinal que apontaria a origem. O gestor anterior deixou a tela bonita e a plataforma doente.

O que o silêncio escondia: plugins em loop

Com os erros suprimidos, ninguém percebia que um ou mais plugins estavam falhando em ciclo. O padrão é conhecido: uma rotina do plugin (muitas vezes uma tarefa agendada pelo cron) tenta rodar, falha, é tentada de novo no ciclo seguinte, e falha outra vez, indefinidamente. Cada tentativa consome recursos e engorda os logs. Multiplique isso por vários ciclos ao dia e você tem a lentidão e a instabilidade que "não tinham causa". Tinham. A causa só estava com a boca tapada.

O diagnóstico: primeiro, acender a luz de novo

O passo número um foi o oposto do que fizeram antes: restaurar a visibilidade. Reativamos o debugging de forma controlada, num momento e ambiente seguros, e lemos os logs reais. Com os erros à mostra, o que era invisível ficou óbvio: dava para ver exatamente qual plugin falhava, com que mensagem e em que rotina. Diagnóstico não se faz no escuro; o primeiro trabalho foi desfazer o escuro que alguém tinha criado de propósito.

A solução

• Remover o código que ocultava os erros: a plataforma volta a ser honesta com quem a opera.
• Tratar cada plugin em loop na causa: corrigir a configuração, atualizar para uma versão compatível ou remover o que estava quebrado e sem uso.
• Ajustar as tarefas agendadas para que parem de repetir a falha.
• Voltar ao estado "limpo", mas do jeito certo: sem erros na tela porque não há erros, e não porque foram escondidos.

O resultado

Com o loop cortado e os plugins tratados, a lentidão e a instabilidade "sem causa" desapareceram: porque a causa deixou de existir, não de ser vista. E a plataforma passou a avisar de verdade quando algo dá errado, que é para isso que servem os erros: não para assustar, mas para apontar onde consertar.

A lição do caso é sobre gestão, não sobre o Moodle: esconder o problema é o contrário de resolvê-lo. Um fornecedor que "deixa a tela limpa" tapando erros está adiando a conta, e ela sempre chega, maior. Sobre os problemas que mais aparecem quando se olha de verdade, veja os erros mais comuns do Moodle; e sobre a lentidão que eles causam, por que o Moodle fica lento.

Perguntas frequentes

Leia também

Suporte MoodleOs erros mais comuns do Moodle (e como resolver)Caso técnico"Database connection failed" no Moodle: quem cuida do seu conhece a diferença?Caso técnicoComprou o curso, virou usuário no Moodle, mas não foi matriculado