Pix pago e pedido pendente no Magento: é o grupo de cron

O módulo do gateway cria um grupo só dele

O Magento vem com três grupos de cron: default, index e consumers. Os módulos de pagamento brasileiros criam os seus.

O Mercado Pago declara mercadopago_adbpayment no etc/cron_groups.xml. O PagBank declara pagbank_paymentmagento_base. É lá dentro que ficam os jobs que vão perguntar ao gateway se aquele pedido foi pago.

Para ver todos os grupos que existem na sua instalação:

grep -rho 'group id="[^"]*"' vendor/*/*/etc/cron_groups.xml app/code/*/*/etc/cron_groups.xml | sort -u

Se aparecer nome de gateway nessa lista, ele precisa rodar.

Destrave o pedido agora

Na raiz da loja, com o usuário dono dos arquivos:

php bin/magento cron:run --group=mercadopago_adbpayment
php bin/magento cron:run --group=pagbank_paymentmagento_base

Uma execução só já gera o agendamento e roda o que estiver vencido. Se o pagamento realmente entrou no gateway, o status do pedido muda em segundos.

Agora a parte que quase ninguém sabe: a frequência desses jobs é bem diferente entre os dois módulos. No PagBank, o pagbank_update_pix roda a cada 30 minutos. No Mercado Pago, o mercadopago_fetch_pix_order_status roda uma vez por dia, às 9 da manhã. Ou seja: se o webhook falhar num Pix pago às 10h, o cron só vai encostar naquele pedido no dia seguinte.

Por que o cron do servidor não pegou o grupo

Veja o que está instalado de verdade:

crontab -l

Se a linha do Magento chama cron:run --group=default e --group=index, o grupo do gateway ficou de fora. Um bin/magento cron:run sem --group roda todos os grupos, inclusive os que forem instalados no futuro. É essa a linha que você quer.

Tem uma armadilha a mais. Os dois módulos marcam use_separate_process como 1, e nesse caso o Magento dispara um processo filho por exec() para aquele grupo. Se o seu php.ini tem exec em disable_functions — coisa comum em hospedagem compartilhada — o grupo nunca roda e nenhum erro aparece na tela. Confere assim:

php -r 'var_dump(function_exists("exec"));'

A janela de 2 minutos que derruba tudo

Os dois módulos configuram schedule_lifetime em 2. Isso é a tolerância, em minutos: se o cron não passar naquele job em até 2 minutos depois do horário agendado, o Magento marca a linha como missed e nunca mais executa aquela ocorrência.

Junte com o job do Mercado Pago que roda às 09:00. Se o cron do seu servidor roda de 5 em 5 minutos, às 09:05 aquele job já virou missed. A conferência do dia inteiro simplesmente não aconteceu, e o pedido segue pendente até amanhã.

Por isso a linha que o próprio bin/magento cron:install escreve roda de minuto em minuto, e não de 5 em 5. Para conferir o estrago, olhe a tabela cron_schedule filtrando por job_code do gateway: se estiver cheio de missed, o problema é frequência, não o módulo.