Chrome ya puede reenviar cualquier petición. Lo que eso te dice y lo que no

Las notas de DevTools de Chrome 152 se publicaron el 25 de agosto de 2026, y una línea de ellas importa más de lo que su tamaño sugiere. La antigua opción de menú Replay XHR del panel Network ahora es simplemente Resend, y la descripción que el propio Chrome hace del cambio es exacta:

Ahora admite todas las peticiones de red que se pueden recuperar, y convierte las peticiones estándar en llamadas fetch() conservando la fidelidad completa de la repetición junto a XHR.

Replay XHR llevaba años en ese menú, útil solo para el tipo concreto de petición que nombraba. Cualquier otra petición fallida - el envío de un formulario, la descarga de un documento, una subida - había que reconstruirla a mano como un comando curl o dentro de un cliente. Ahora haces clic derecho sobre ella y la envías otra vez.

La misma versión da a la pestaña Payload opciones de decodificación - Base64, Hex y UTF-8 - para cuerpos de petición binarios y comprimidos, reflejando lo que la pestaña Response ya ofrecía. Cualquiera que haya mirado una subida de archivo fallida o un cuerpo comprimido sin ver nada aprovechable tiene ahora tres formas de leerlo.

Por qué esto importa cuando la petición no era tuya

Ambos cambios caen sobre la misma actividad: averiguar qué pasó a partir de una petición que no hiciste tú.

Eso es la mayoría de los informes de errores. Alguien se topó con un fallo, la petición fallida está delante de ti, y la pregunta es si puedes llegar desde ella hasta una causa. Poder reenviarla con un clic, y leer un cuerpo que antes era opaco, quita dos recados de ese trabajo.

La parte con la que conviene tener cuidado

Un reenvío no es la petición que falló. Es una petición nueva que se le parece.

Sale de tu navegador, con tus cookies, tu sesión, tus extensiones y tu dirección IP, en un momento que no es el momento en que falló originalmente. Son cuatro diferencias antes de que hayas cambiado nada, y cada una de ellas puede dar la vuelta al resultado:

Lo que responde un reenvío

¿Falla esta forma de petición para mí, desde aquí, ahora mismo?

Lo que tiene que responder el informe

¿Por qué falló esta petición para aquella persona, en su sesión, en aquel momento?

Un 403 que al reenviarlo devuelve un 200 suele significar que la diferencia estaba en la sesión y no en la petición. Un 500 que al reenviarlo sigue siendo un 500 es un regalo, porque tienes una reproducción que controlas. Un tiempo de espera agotado que al reenviarlo responde al instante te está diciendo que el estado que lo causó ya pasó, que es exactamente el caso del 504.

Nada de eso hace que Resend sea menos útil. Lo convierte en una primera pregunta en lugar de en una respuesta, y saber cuál de las dos tienes en la mano es toda la habilidad.

Lo que el informe tiene que llevar para que algo de esto funcione

No puedes reenviar una petición que no tienes. Lo que hace que esta nueva capacidad sea siquiera alcanzable es si la petición fallida sobrevivió al viaje desde la persona que la vio hasta la persona que la arregla, con su método, su URL, sus cabeceras y su cuerpo intactos.

Para eso está el registro de red en un informe de error, y por eso existen los archivos HAR como formato.

Un límite honesto de nuestro lado: enmascaramos por defecto las cabeceras y los valores de credenciales, y en un dominio que no ha pedido otra cosa los enmascaramos en todas partes. Así que una petición repetida a partir de un informe que capturamos nosotros necesitará normalmente que la autorización la aporte quien la repite. Ese es el intercambio que elegimos - un informe es un enlace que alguien puede abrir, así que todo lo capturado queda de hecho compartido - y conviene saberlo antes de preguntarse por qué el reenvío volvió sin autorización.

El resto de la versión, en resumen

Otras tres cosas de las mismas notas merecen el minuto de un desarrollador.

Copy as preload element. Haz clic derecho sobre una petición y obtienes una etiqueta <link rel="preload"> lista para pegar, lo que convierte una observación de rendimiento en una edición sin el paso intermedio de buscar la sintaxis.

Exportación estructurada de tablas en la consola, para que una tabla que hayas registrado pueda salir de la consola como datos y no como una captura de pantalla de datos.

Cambiar entre el árbol del DOM y el árbol de accesibilidad desde el menú contextual de Elements, con “scroll into view” para los nodos de accesibilidad. Pequeño, y baja el coste de comprobar lo que la mayoría de los equipos comprueba menos.

Qué sacar de todo esto

Una nota de versión de un navegador no suele merecer una segunda lectura, y esta sí, por una razón que no tiene nada que ver con el tamaño de las funciones: mejora las herramientas alrededor de las pruebas que recogió otra persona. Esa es una categoría en la que la mayoría de las herramientas de depuración han sido históricamente pobres, porque dan por hecho que quien tiene el navegador delante es quien encontró el error.

Normalmente no son la misma persona. Cualquier cosa que acorte la distancia entre las dos vale más de lo que sugiere su nota de versión.

Las notas del propio Chrome son el sitio donde leer la lista completa: What’s new in DevTools (Chrome 152).