Solucionar errores de actualización del tiempo de ejecución

Browser con script: los intentos de interactuar con elementos fallan

Al validar un monitor creado en un runtime anterior con el runtime de Chrome 100 (o posterior), findElement y otros métodos para encontrar e interactuar con elementos de la página pueden fallar debido a diferencias en el manejo de promesas. Si el monitor pasa en un tiempo de ejecución heredado, falla en el nuevo tiempo de ejecución y el elemento está presente en la captura de pantalla, es posible que deba mejorar su lógica de manejo de promesas.

El administrador de promesas y el flujo de control de Selenium WebDriver permitían que algunas funciones se ejecutaran en orden en tiempos de ejecución heredados, sin administrar promesas. Esta capacidad se eliminó en Selenium WebDriver 4.0 y ya no está disponible en el tiempo de ejecución. Todas las funciones asíncronas y promesas deben manejarse con await o con cadenas de promesas .then. Esto asegurará que las funciones del script se ejecuten en el orden esperado.

Por ejemplo, el gestor de promesas y el flujo de control podrían permitir que este script parcial se complete correctamente, aunque $browser.get devuelva una promesa y la promesa no se esté manejando correctamente:

$browser.get('http://example.com');

$browser.findElement($driver.By.css('h1'));

En el tiempo de ejecución de Chrome 100 (o posterior), los métodos que devuelven una promesa deben usar await o la sintaxis .then para secuenciar correctamente los pasos. Se recomienda utilizar await debido a una sintaxis más limpia y mayor facilidad de uso, pero las cadenas de promesas .then aún son compatibles.

await $browser.get('http://example.com');

let el = await $browser.findElement($driver.By.css('h1'));

API con secuencia de comandos: diferencias entre request y got

Los tiempos de ejecución de API con scripts de Node.js 10 y anteriores utilizaban el módulo request de Node.js para proporcionar un objeto $http que podía utilizarse para probar APIs.

Los tiempos de ejecución de API con scripts de Node.js 16 y versiones posteriores utilizan got en lugar de request. El módulo request quedó obsoleto en 2020 y ya no se incluirá en las nuevas API o tiempos de ejecución basados en navegador. El objeto $http proporciona una experiencia personalizada similar a requestal estar impulsado por got para ofrecer compatibilidad con versiones anteriores para casos de uso básicos, evitando al mismo tiempo el uso de un módulo obsoleto. No todos los casos de uso avanzados de request son o serán compatibles. Hay ejemplos de scripts y una guía de conversión disponibles.

API con scripts: Token inesperado JSON.parse

Intentar utilizar la función JSON.parse mientras se interactúa con el cuerpo de la respuesta puede producir errores de token inesperados en el monitor de API con secuencia de comandos que utiliza Node.js 16 y el tiempo de ejecución más reciente. Si el encabezado de respuesta del tipo de contenido es application/json, el cuerpo de la respuesta que devuelve el objeto $http se analizará en formato JSON. Las llamadas adicionales que intenten utilizar JSON.parse para analizar el cuerpo de la respuesta fallarán con este error porque el cuerpo de la respuesta ya se ha analizado.

Si el encabezado de respuesta content-type no es application/json, el cuerpo de la respuesta no se analizará automáticamente y aún será necesario utilizar la función JSON.parse.

API con scripts: HEAD o GET

No puede incluir un cuerpo de solicitud en una solicitud HTTP HEAD o GET. El módulo request utilizado por el entorno de ejecución de Node 10 y anteriores permitía esto, pero esto causará errores en el nuevo entorno de ejecución. Algunas configuraciones diferentes pueden causar el error, pero las sugerencias más comunes incluyen:

• No incluya un cuerpo en su solicitud, incluso si está vacío.
• Evite opciones innecesarias en su solicitud HEAD o GET, como json: true

Scripted API: Diferencias en la cadena de consulta (qs)

En los entornos de ejecución de Node 10 o anteriores, las configuraciones de la cadena de consulta se pasaban usando la opción qs:. Para el entorno de ejecución de Node 16, utilice la opción searchParams: en su lugar. Solo debe cambiar el nombre de la opción. No debería ser necesario actualizar el contenido de la cadena de consulta.

API con scripts: Diferencias en el cookie jar

En los entornos de ejecución de Node 10 o anteriores, podía utilizar la opción jar: true para almacenar cookies en un cookie jar entre solicitudes.

En el runtime de Node 16, debe crear un cookie jar usando el módulo tough-cookie y luego hacer referencia a ese cookie jar en su solicitud en su lugar. Si creó un cookie jar llamado cookies, haga referencia a él en sus opciones como cookieJar: cookies

API con scripts: Diferencias de formulario

Debido a las diferencias entre el módulo request utilizado para el objeto $http en Node 10 y tiempos de ejecución anteriores, y el módulo got que se utiliza para el objeto $http en el tiempo de ejecución de Node 16, es posible que experimente problemas con las solicitudes que utilizan formularios en los monitores de API.

Si es así, utilice el módulo form-data para crear e incluir su formulario con su solicitud como se muestra en este ejemplo parcial.

const FormData = require('form-data');

let form = new FormData();
form.set('fieldName1','value1');
form.set('fieldName2','value2');

let req = {
  headers: {
    'Authorization': 'Bearer ' + token,
    'Content-Type': 'multipart/form-data',
  },
  body: form
}

Diferencias de versión del módulo UUID

El tiempo de ejecución de Node 16 incluye una versión más reciente del módulo uuid que fuerza el uso de la sintaxis actualizada de require.

Node 10 y anteriores: const uuid = require('uuid');

Node 16 (asumiendo el uso de uuidv4): const { v4: uuidv4 } = require('uuid');

Navegador de scripts: Advertencias de obsolescencia ($browser y $driver

Las advertencias de obsolescencia para $browser y $driver se eliminaron a partir de la versión 2.0.29 o posterior del tiempo de ejecución del navegador. Ya no debería recibir estas advertencias al usar ubicaciones públicas. Por favor, actualice su imagen de tiempo de ejecución de navegador Node si recibe estas advertencias al usar ubicaciones privadas.

Scripted browser: waitForAndFindElement y waitForPendingRequests

Los métodos waitForAndFindElement y waitForPendingRequests son métodos personalizados de New Relic que se proporcionan en Chrome 72 y en tiempos de ejecución browser con secuencias de comandos anteriores. Todavía se pueden usar con $driver y $browser en Chrome 100 y tiempos de ejecución más recientes, pero no estarán disponibles cuando se usan las API de Selenium Webdriver 4.1 directamente con $selenium y $webDriver. Este cambio alineará mejor la implementación de Selenium Webdriver de New Relic con la implementación básica de Selenium Webdriver .

Los clientes que opten por seguir usando waitForAndFindElement o waitForPendingRequests en el nuevo tiempo de ejecución pueden pegar ejemplos de código en sus monitores.