O Quality Patches Tool 1.1.85 Magento reúne correções que merecem atenção de lojas com clientes autenticados, checkout por API e carrinho persistente. Dois sintomas são especialmente relevantes: mais de um carrinho ativo criado por solicitações concorrentes e perda indevida do carrinho depois que a sessão expira.
Aplicar todos os patches disponíveis sem confirmar a compatibilidade, porém, não é uma estratégia segura. O procedimento deve começar pelo diagnóstico do sintoma, passar pela consulta de aplicabilidade e terminar com testes de carrinho, descontos, frete, pagamento e integrações em homologação.
O que mudou no Quality Patches Tool 1.1.85 Magento?
A versão 1.1.85 inclui o ACP2E-5077, patch destinado a corrigir a criação de carrinhos ativos duplicados quando solicitações concorrentes usam a consulta customerCart do GraphQL ou o endpoint POST /V1/carts/mine da API REST para um cliente que ainda não possui carrinho ativo, conforme as notas oficiais do Quality Patches Tool 1.1.85.
A mesma versão lista o ACP2E-5088, relacionado à limpeza do carrinho persistente do cliente quando a sessão expira, de acordo com as notas de versão publicadas pela Adobe. Na prática, esse cenário merece atenção em lojas nas quais compradores autenticados montam o carrinho, deixam o site e retornam posteriormente.
O Quality Patches Tool permite consultar, aplicar e reverter patches individuais no Adobe Commerce e no Magento Open Source, respeitando a versão instalada, como explica a documentação oficial da ferramenta. Isso permite tratar um defeito específico sem transformar a intervenção em uma atualização geral da aplicação.
Como esses problemas podem aparecer na operação?
Carrinhos ativos duplicados
Uma loja pode disparar requisições próximas ou simultâneas por diferentes motivos: carregamento duplicado no storefront, repetição automática feita por um cliente HTTP, aplicativo móvel, frontend headless ou integração que consulta o carrinho após a autenticação. O diagnóstico não deve partir da suposição de que toda duplicidade tem a mesma origem.
Antes de relacionar o comportamento ao ACP2E-5077, registre o identificador do cliente, os horários das chamadas, os IDs retornados, o canal utilizado e os cabeçalhos de correlação disponíveis. Também verifique se existe repetição provocada pelo frontend, proxy, gateway ou mecanismo de retry. O patch trata uma condição específica; ele não elimina chamadas duplicadas geradas por uma customização.
Carrinho persistente perdido após expiração da sessão
A expiração da sessão não deveria ser investigada apenas como uma falha de login. Para o cliente, o sintoma mais evidente pode ser o desaparecimento dos itens que ele esperava encontrar ao retornar. Cookies, configuração de persistência, escopo do site, domínio, cache e módulos de autenticação também participam desse fluxo.
Registre quanto tempo o carrinho permaneceu inativo, se o cliente estava autenticado, em qual site ou visão de loja ele navegava e o que ocorreu após um novo login. Faça o teste com um produto simples e estoque controlado para evitar que indisponibilidade ou mudança de preço seja confundida com perda do carrinho.
Como verificar versão e aplicabilidade antes de instalar
Comece identificando a versão do pacote presente no projeto, sempre no mesmo código e ambiente que serão usados na homologação:
composer show magento/quality-patches
php bin/magento --version
vendor/bin/magento-patches statusPreserve a saída desses comandos no chamado técnico. O estado pode indicar que um patch está disponível, aplicado, incompatível ou substituído, dependendo da combinação de versão e código. Consulte também a lista oficial de patches disponíveis para conferir as versões às quais cada correção se aplica.
Se o pacote precisar ser alterado, trate essa mudança como dependência de projeto: faça-a em uma branch própria, preserve o composer.lock e revise o conjunto de pacotes modificado. Caso o Composer apresente conflito, siga um diagnóstico direcionado em vez de executar uma atualização irrestrita; este guia sobre erro no Composer do Magento 2 ajuda a localizar o bloqueio.
Roteiro para homologar o ACP2E-5077
- Crie um cliente de teste sem carrinho ativo. Não reutilize uma conta que tenha histórico desconhecido ou carrinho persistente pendente.
- Registre o estado inicial. Confirme que o cliente não possui um carrinho ativo antes de iniciar as chamadas.
- Reproduza o canal usado pela loja. Teste separadamente GraphQL e REST quando ambos forem consumidos. Não conclua pedidos nessa etapa.
- Envie chamadas concorrentes controladas. Use poucas solicitações, em homologação, salvando horário, resposta HTTP, corpo retornado e identificador do carrinho.
- Compare antes e depois do patch. O critério não deve ser apenas a ausência de erro na API. Confirme quantos carrinhos ativos foram associados ao cliente e se as respostas apontam para o fluxo esperado.
- Repita com o frontend real. Valide login, inclusão de item, alteração de quantidade, cupom, estimativa de frete e acesso ao checkout.
Em operações headless, mudanças no carrinho podem repercutir em contratos e consumidores diferentes. O roteiro de testes de GraphQL e REST no Adobe Commerce pode complementar a validação das integrações.
Como testar sessão persistente, descontos e checkout
Para o ACP2E-5088, monte um carrinho com uma conta de teste, anote itens, quantidades, preços e cupom, aguarde a expiração configurada da sessão e volte pelo mesmo fluxo usado pelo cliente. Em seguida, autentique-se novamente e confira se o carrinho esperado foi preservado conforme a configuração da loja.
Embora os fatos documentados para esses dois patches estejam ligados ao carrinho e à sessão, as regras de preço devem entrar como teste de regressão. Preservar um carrinho não basta se, no retorno, um cupom deixa de ser aplicado, uma promoção expirada permanece ativa ou os totais são recalculados incorretamente.
- teste produto simples, configurável e, quando aplicável, bundle;
- aplique e remova um cupom válido;
- confira subtotal, desconto, frete, impostos e total;
- altere endereço e método de entrega;
- valide PIX, cartão, antifraude e demais pagamentos habilitados;
- confirme que ERP, estoque e emissão fiscal não recebem eventos antes da criação real do pedido;
- verifique o comportamento com cliente autenticado e checkout de convidado.
Se o fluxo parar na etapa final, não atribua automaticamente a falha ao patch. Preserve as requisições e os logs e use um procedimento como o de diagnóstico de checkout Magento 2 para localizar a camada responsável.
Aplicação, reversão e publicação controlada
Depois de confirmar a aplicabilidade, faça backup compatível com a arquitetura, registre o estado atual e aplique somente o identificador aprovado em homologação. Os comandos operacionais devem ser executados conforme a versão da ferramenta e a documentação consultada:
vendor/bin/magento-patches apply ACP2E-5077
vendor/bin/magento-patches statusPara o outro cenário, substitua o identificador por ACP2E-5088. Revise as alterações no código, execute o processo normal de build e deploy e repita os testes funcionais. Não edite manualmente os arquivos gerados pelo patch.
Se a homologação reprovar e a reversão for suportada no estado encontrado, utilize o mecanismo da própria ferramenta e confirme novamente o status:
vendor/bin/magento-patches revert ACP2E-5077
vendor/bin/magento-patches statusA publicação em produção deve ter janela definida, plano de retorno e monitoramento de logs de aplicação, respostas das APIs, criação de carrinhos e conversão do checkout. Evite testar concorrência com tráfego real ou criar pedidos apenas para descobrir se a instalação funcionou.
Perguntas frequentes
O QPT 1.1.85 é compatível com qualquer versão do Magento?
Não se deve presumir compatibilidade universal. Consulte o status apresentado pela ferramenta e a lista oficial de patches para a versão exata do Adobe Commerce ou Magento Open Source instalada.
Como verificar se o ACP2E-5077 é aplicável?
Confirme a versão do pacote magento/quality-patches, execute o comando de status e compare o resultado com a documentação oficial. Faça a aplicação somente em uma branch e ambiente de homologação.
É possível testar carrinhos duplicados sem criar pedidos?
Sim. O teste pode terminar após a consulta ou criação controlada do carrinho, verificando os identificadores retornados e o estado associado ao cliente. Não é necessário enviar o pedido ou acionar pagamento.
O que validar depois de aplicar o patch?
Valide login, carrinho persistente, itens, quantidades, cupons, regras de preço, frete, totais, checkout, pagamentos e integrações. Compare evidências coletadas antes e depois da aplicação.
Conclusão
O Quality Patches Tool 1.1.85 Magento oferece correções pontuais para cenários que podem afetar a continuidade da compra, mas a aplicação deve ser orientada por sintoma, versão e evidências. Verifique a aplicabilidade, reproduza o problema em homologação e teste carrinho, sessão, descontos e checkout antes da produção. Se a loja não possui ambiente seguro ou rastreabilidade suficiente, uma revisão técnica especializada pode reduzir o risco da intervenção.
Fontes consultadas
As informações atuais mencionadas neste artigo foram verificadas nas fontes abaixo.
