Troubleshoot runtime upgrade errors

Scripted Browser: Attempts to interact with elements fail

When validating a monitor created in an older runtime against the Chrome 100 (or newer) runtime, findElement and other methods to find and interact with elements on the page may fail due to promise handling differences. If the monitor passes in a legacy runtime, fails in the new runtime, and the element is present in the screenshot, you may need to improve your promise handling logic.

Selenium WebDriver promise manager and control flow allowed some functions to execute in order in legacy runtimes, without managing promises. This capability was removed in Selenium WebDriver 4.0 and is no longer available in the runtime. All async functions and promises need to be managed with await or with .then promise chains. This will ensure script functions execute in the expected order.

For example, promise manager and control flow could allow this partial script to complete successfully, even though $browser.get returns a promise and the promise is not being handled correctly:

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

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

In the the Chrome 100 (or newer) runtime, any methods that return a promise need to use await or .then syntax to properly sequence steps. Using await is recommended due to cleaner syntax and easier usage, but .then promise chains are still supported too.

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

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

Scripted API: Differences between request and got

The Node.js 10 and older scripted API runtimes used the request Node.js module to provide a $http object that could be used to test APIs.

The Node.js 16 and newer scripted API runtimes use got instead of request. The request module was deprecated in 2020 and will no longer be included in new API or browser based runtimes. The $http object provides a custom request-like experience while being powered by got to provide backward compatibility for basic use cases while still avoiding the use of a deprecated module. Not all advanced use cases of request are or will be supported. There are script examples and a conversion guide available.

Scripted API: Unexpected token JSON.parse errors

Attempting to use the JSON.parse function while interacting with the response body may produce unexpected token errors in scripted API monitors using the Node.js 16 and newer runtime. If the content-type response header is application/json, the response body being returned by the $http object will be parsed JSON. Additional calls attempting to use JSON.parse to parse the response body will fail with this error because the response body has already been parsed.

If the content-type response header is not application/json, the response body will not automatically be parsed and the JSON.parse function will still need to be used.

Scripted API: HEAD or GET request cannot be used with a body

You cannot include a request body with a HTTP HEAD or GET request. The request module used by the Node 10 and older runtime allowed this, but this will cause errors in the new runtime. A few different configurations can cause the error a few different configurations, but the most common suggestions include:

• Do not include a body in your request, even if it's empty.
• Avoid unnecessary options on your HEAD or GET request, like json: true

Scripted API: Query string (qs) differences

In the Node 10 or older runtimes, query string configurations were passed using the qs: option. For the Node 16 runtime, please use the searchParams: option instead. Only the name of the option needs to change. The content of the query string should not need to be updated.

Scripted API: Cookie jar differences

In the Node 10 or older runtimes you could use the option jar: true to store cookies in a cookie jar between requests.

In the Node 16 runtime you must create a cookie jar using the tough-cookie module and then refer to that cookie jar in your request instead. If you created a cookie jar named cookies, refer to it in your options as cookieJar: cookies

Scripted API: Form differences

Due to differences between the request module used for the $http object in Node 10 and older runtimes and the got module that's used for the $http object in the Node 16 runtime, you may encounter issues with requests using forms in API monitors.

If so, please use the form-data module to create and include your form with your request as shown in this partial example.

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
}

UUID module version differences

The Node 16 runtime includes a newer version of the uuid module that forces the use of updated require syntax.

Node 10 and older: const uuid = require('uuid');

Node 16 (assuming use of uuidv4): const { v4: uuidv4 } = require('uuid');

Scripted browser: Deprecation warnings ($browser and $driver)

Deprecation warnings for $browser and $driver were removed starting with the 2.0.29 or newer version of the browser runtime. You should no longer receive these warnings when using public locations. Please update your node browser runtime image if you're receiving these warnings when using private locations.

Scripted browser: waitForAndFindElement and waitForPendingRequests

The waitForAndFindElement and waitForPendingRequests methods are New Relic custom methods that are provided in the Chrome 72 and older scripted browser runtimes. They can still be used with $driver and $browser in the Chrome 100 and newer runtimes, but they will not be available when using the Selenium WebDriver 4.1 APIs directly with $selenium and $webDriver. This change will better align New Relic's Selenium WebDriver implementation with the base Selenium WebDriver implementation.

Customers who choose to continue using waitForAndFindElement or waitForPendingRequests in the new runtime can paste code examples into their monitors.