O Chrome já consegue reenviar qualquer pedido. O que isso lhe diz e o que não diz

As notas de DevTools do Chrome 152 saíram a 25 de agosto de 2026, e uma linha delas importa mais do que o seu tamanho sugere. A antiga entrada de menu Replay XHR do painel Network passou a ser simplesmente Resend, e a descrição que o próprio Chrome faz da mudança é exata:

Passa a suportar todos os pedidos de rede que podem ser obtidos, convertendo os pedidos padrão em chamadas fetch() e preservando a fidelidade total da repetição a par do XHR.

O Replay XHR esteve naquele menu durante anos, útil apenas para o tipo específico de pedido que nomeava. Qualquer outro pedido falhado - o envio de um formulário, a obtenção de um documento, um carregamento - tinha de ser reconstruído à mão como comando curl ou dentro de um cliente. Agora clica nele com o botão direito e envia-o outra vez.

A mesma versão dá ao separador Payload opções de descodificação - Base64, Hex e UTF-8 - para corpos de pedido binários e comprimidos, espelhando o que o separador Response já oferecia. Quem já olhou para um carregamento de ficheiro falhado ou para um corpo comprimido e não viu nada aproveitável tem agora três formas de o ler.

Porque é que isto importa quando o pedido não foi seu

As duas mudanças caem sobre a mesma atividade: perceber o que aconteceu a partir de um pedido que não foi você a fazer.

É esse o caso da maioria dos relatórios de erro. Alguém deu de caras com uma falha, o pedido falhado está à sua frente, e a pergunta é se consegue chegar dele até uma causa. Poder reenviá-lo com um clique, e ler um corpo que antes era opaco, retira dois recados desse trabalho.

A parte com que vale a pena ter cuidado

Um reenvio não é o pedido que falhou. É um pedido novo que se parece com ele.

Parte do seu navegador, com os seus cookies, a sua sessão, as suas extensões e o seu endereço IP, num momento que não é aquele em que falhou originalmente. São quatro diferenças antes de ter mudado seja o que for, e cada uma delas pode virar o resultado:

O que um reenvio responde

Esta forma de pedido falha para mim, a partir daqui, agora mesmo?

O que o relatório tem de responder

Porque é que este pedido falhou para aquela pessoa, na sessão dela, naquele momento?

Um 403 que ao ser reenviado devolve 200 costuma significar que a diferença estava na sessão e não no pedido. Um 500 que ao ser reenviado continua a ser 500 é uma prenda, porque tem uma reprodução que controla. Um tempo de espera esgotado que ao ser reenviado responde de imediato está a dizer-lhe que o estado que o causou já passou, que é exatamente o caso do 504.

Nada disto torna o Resend menos útil. Torna-o uma primeira pergunta em vez de uma resposta, e saber qual das duas tem na mão é a competência toda.

O que o relatório tem de levar para que algo disto funcione

Não pode reenviar um pedido que não tem. O que torna esta nova capacidade sequer alcançável é se o pedido falhado sobreviveu à viagem da pessoa que o viu até à pessoa que o corrige, com o seu método, o seu URL, os seus cabeçalhos e o seu corpo intactos.

É para isso que serve um registo de rede num relatório de erro, e é por isso que os ficheiros HAR existem como formato.

Um limite honesto do nosso lado: mascaramos por omissão os cabeçalhos e os valores de credenciais, e num domínio que não pediu outra coisa mascaramo-los em todo o lado. Por isso, um pedido repetido a partir de um relatório que capturámos vai precisar normalmente que a autorização seja fornecida por quem o está a repetir. Foi a troca que escolhemos - um relatório é um link que alguém pode abrir, por isso tudo o que é capturado fica na prática partilhado - e vale a pena saber isto antes de se perguntar porque é que o reenvio voltou sem autorização.

O resto da versão, em resumo

Há outras três coisas nas mesmas notas que valem o minuto de um programador.

Copy as preload element. Clique com o botão direito num pedido e recebe uma etiqueta <link rel="preload"> pronta a colar, o que transforma uma observação de desempenho numa alteração sem o passo intermédio de ir procurar a sintaxe.

Exportação estruturada de tabelas na consola, para que uma tabela que registou possa sair da consola como dados e não como uma captura de ecrã de dados.

Alternar entre a árvore do DOM e a árvore de acessibilidade a partir do menu de contexto em Elements, com “scroll into view” para os nós de acessibilidade. Pequeno, e baixa o custo de verificar aquilo que a maioria das equipas verifica menos.

O que retirar daqui

Uma nota de versão de um navegador não costuma merecer uma segunda leitura, e esta merece, por um motivo que nada tem a ver com o tamanho das funcionalidades: melhora as ferramentas à volta de provas que outra pessoa recolheu. É uma categoria em que a maioria das ferramentas de depuração tem sido historicamente fraca, porque partem do princípio de que quem tem o navegador à frente é quem encontrou o erro.

Normalmente não são a mesma pessoa. Tudo o que encurte a distância entre as duas vale mais do que a sua nota de versão sugere.

As notas do próprio Chrome são o sítio onde ler a lista completa: What’s new in DevTools (Chrome 152).