Como reportar um bug da loja Magento para o dev resolver na primeira tentativa

Modelo de chamado de erro para o desenvolvedor Magento

Quando recebo um chamado, a primeira pergunta é se consigo repetir o erro só com o que está escrito. Se não consigo, a primeira hora vai embora em perguntas. Copie o modelo e preencha todos os campos; o que não se aplica recebe “não se aplica”.

Assunto: [nome da loja] resumo do erro em uma linha

1. Onde: URL completa da página
2. Loja: store view (ex.: Loja Brasil, English, Atacado)
3. Quem: visitante ou cliente logado; se logado, o grupo de cliente
4. Passos para repetir:
   1) ...
   2) ...
   3) ...
5. Esperado: o que deveria acontecer
6. Obtido: o que aconteceu, com a mensagem copiada como texto
7. Quando: data e hora com fuso (03/11/2026 14:12, horário de Brasília)
8. Referência: número do pedido ou SKU (nada de dado do cliente)
9. Aparelho: computador ou celular, navegador e versão
10. Evidências: Error log record number, prints do console e da aba Rede
11. Frequência: sempre, às vezes ou uma vez só
12. O que mudou antes: deploy, extensão nova, promoção, importação

Os campos 2 e 3 parecem detalhe, mas são o que o Magento usa para decidir o que mostrar. O 12 aponta onde olhar primeiro.

Por que o dev Magento pergunta a store view e o grupo de cliente

Na mesma loja Magento, duas pessoas abrindo a mesma URL podem ver preço, desconto e texto diferentes:

• Grupo de cliente. Regra de carrinho e regra de preço de catálogo valem para os grupos de cliente escolhidos. Quem compra sem login entra no grupo NOT LOGGED IN. O cupom que “não funciona” pode estar certo para esse grupo e errado para o Atacado.
• Store view. Configurações e textos podem ter valor próprio por website ou por store view, como expliquei no artigo sobre escopo global, website e store view.
• Visitante ou logado. No código do checkout padrão do Magento 2.4.9, o botão de finalizar compra chama um endereço da API para quem está logado (carts/mine/payment-information) e outro para quem compra como visitante (guest-carts/.../payment-information).

O que é o Error log record number e o que fazer com ele

Quando o Magento encontra um erro que não consegue tratar, ele mostra a página There has been an error processing your request com a linha Error log record number e um código. Segundo a documentação da Adobe, em modo de produção o detalhe vai para arquivo e nunca aparece ao visitante. O código do Magento 2.4.9 mostra três coisas sobre esse número:

1. Ele tem 64 caracteres, só números e letras de a até f. Selecione o texto na tela e cole no chamado, além do print.
2. Ele fica em dois lugares no servidor: no relatório gravado dentro de var/report/ e na linha do var/log/exception.log, onde aparece como report_id. A documentação da Adobe para a nuvem mostra exatamente essa busca pelo número no exception.log.
3. Ele é calculado a partir da mensagem, do caminho do erro e da URL. O mesmo erro na mesma página tende a repetir o número; se ele muda a cada tentativa, escreva isso.

Preço errado ou cupom recusado não geram essa página: aí a evidência são os passos, os prints e a aba Rede.

Data e hora do erro: o log do Magento grava em UTC

O Magento fixa o fuso UTC no arquivo de inicialização, o app/bootstrap.php. As linhas do exception.log começam com data e hora nesse fuso. Nas versões recentes, como o 2.4.8 e o 2.4.9, a hora termina em +00:00; em lojas antigas, vem sem esse final, mas no mesmo fuso. O formato é este (exemplo com os dados trocados):

[2026-11-03T17:12:40.118204+00:00] main.CRITICAL: mensagem do erro {"report_id":"...","exception":"..."} []

Por isso, no chamado, escreva sempre o fuso junto com a hora: “03/11 às 14h12, horário de Brasília”. O dev converte a hora para UTC e vai direto ao trecho certo. Hora sem fuso obriga a procurar em duas janelas. Você não precisa abrir o log: dê a hora exata e o número, de preferência com o relógio do computador aparecendo no print.

Como tirar print do console e da aba Rede do navegador

Botão que não responde e checkout que fica girando deixam rastro no navegador, não na tela:

1. Abra as ferramentas do desenvolvedor com F12 (no Chrome do Mac, Cmd+Option+I).
2. Na aba Console, as linhas em vermelho são erros, de JavaScript ou de arquivo que não carregou. Tire print delas.
3. Na aba Rede (Network), marque Preservar registro (Preserve log), para a lista não sumir quando a página muda, e repita a ação que falhou.
4. Procure a linha em vermelho ou com status 400 ou 500, clique nela e tire print da aba Resposta (Response), onde fica a mensagem devolvida pela loja.

No checkout, o endereço chamado começa com rest/, seguido do código da store view, e termina em payment-information. Se a compra falha, é essa linha que interessa. Cuidado com a aba Payload da mesma chamada: pelo código do checkout, ela leva o endereço de cobrança, os dados do meio de pagamento e, na compra como visitante, o e-mail do comprador. Print da resposta, sim; print do payload, não.

Como informar o pedido sem expor dados do cliente

Chamado passa por e-mail, WhatsApp e ferramenta de tarefas, e fica guardado em lugares que ninguém apaga. Dado pessoal não entra. O que mandar no lugar:

Com o número do pedido, o dev encontra tudo no admin, com o próprio usuário e as permissões que você liberou. Se ele ainda não tem acesso, veja como dar acesso à loja Magento para um dev sem entregar a sua senha.

Chamado ruim e chamado bom, lado a lado

O exemplo abaixo é fictício, montado para mostrar a diferença:

O chamado bom leva poucos minutos a mais e o dev começa pela causa. Se o erro depende de dados reais, peça que ele repita primeiro no ambiente de staging, e não com testes na loja que está vendendo.