Quem opera Magento 2 em produção/ambientes de staging já deve ter trombado com dois problemas que parecem “aleatórios”, mas têm uma origem bem objetiva:

1. Consumidores/filas de resize falhando com “Cannot resize image … original image not found”.
2. Duplicação de produto falhando com “We couldn't copy file … Please delete media with non-existing images and try again.”

Neste artigo, vamos explicar por que isso acontece e mostrar uma abordagem prática (via módulos leves) para estabilizar o comportamento.

• Resize / queue / consumer
  • Cannot resize image "/path/to/pub/media/catalog/product/..." - original image not found
  • Cannot resize image "..." - original image not found
• Duplicate product / media gallery
  • We couldn't copy file %1. Please delete media with non-existing images and try again.
  • We couldn't copy file catalog/product/x/y/file.jpg. Please delete media with non-existing images and try again.

1) Quando o resize é assíncrono, o “filename” pode ficar desatualizado

O sintoma

Você envia uma imagem no Admin, salva o produto e, ao processar a fila/consumer de resize, aparecem falhas do tipo:

Cannot resize image "/.../pub/media/catalog/product/x/y/arquivo.jpg" - original image not found

O ponto importante: o Magento está tentando redimensionar um arquivo que não existe no caminho informado.

A causa raiz (não é “RabbitMQ”, é fluxo do Admin)

No Admin do Magento, o resize pode ser agendado assíncronamente via message queue (mesmo em DB queue). Esse agendamento é feito por um observer core após o commit do produto.

Ao mesmo tempo, o fluxo de upload de imagem do produto passa por duas fases:

• Upload inicial em pub/media/tmp/catalog/product/...
• Move do tmp para pub/media/catalog/product/... no save

E é aqui que o comportamento surpreende: durante o move, o Magento pode renomear o arquivo para evitar colisão (ou por sanitização). Ou seja: você sobe imagem-teste.jpg, mas no destino final ela vira imagem-testeXyZ1.jpg.

Se o resize foi agendado com o nome anterior, a fila fica apontando para um caminho que nunca existirá no catalog/product e o consumer quebra.

A correção: enfileirar com o nome persistido

A correção mais robusta é: no momento de agendar o resize, usar somente os filenames persistidos no banco (após o save), e não o payload “transitório” da request.

Uma forma pragmática de fazer isso é criar um módulo (adminhtml) que intercepta o observer core e:

• recarrega o produto já persistido;
• agenda o resize usando getMediaGalleryImages() (arquivos finais);
• enfileira apenas o “diff” entre imagens antigas e novas.

Resultado: o resize deixa de apontar para nomes “stale”, e os erros de “original image not found” desaparecem.

2) Duplicação de produto falha quando a galeria referencia arquivos inexistentes

O sintoma

Ao duplicar um produto no Admin e salvar, o Magento retorna:

We couldn't copy file catalog/product/.../file.jpg. Please delete media with non-existing images and try again.

A causa raiz

Na duplicação, o core tenta copiar as imagens existentes do produto para criar o novo produto duplicado. Se o banco ainda referencia um arquivo que foi removido do disco (ou nunca existiu de fato), o core interrompe a duplicação e lança a exceção.

Esse cenário é mais comum do que parece:

• uploads antigos que foram apagados manualmente;
• sincronizações incompletas de pub/media;
• migrações/staging com media incompleta.

A correção: filtrar referências quebradas na duplicação

Se o objetivo é “não travar o trabalho do usuário”, dá para criar um plugin específico para o fluxo de duplicação que:

• remove da payload de media_gallery as imagens cujo arquivo não existe no pub/media/catalog/product;
• opcionalmente, limpa image/small_image/thumbnail caso apontem para arquivos ausentes.

A duplicação volta a funcionar e o produto duplicado é criado sem as mídias inválidas.

Conclusão

Esses problemas têm um padrão: o Magento é muito sensível a divergências entre o que o banco referencia e o que existe no filesystem, e o Admin introduz uma camada assíncrona que pode expor “race conditions” com rename/move.

Com patches pequenos e bem localizados (adminhtml), dá para:

• estabilizar o resize por fila;
• evitar travas na duplicação por mídia ausente.