I've been using Chromeless with chrome-launcher, to POC a test. Here's my code:
const chromeLauncher = require('chrome-launcher');
const { Chromeless } = require('chromeless');
async function launchHeadlessChrome() {
try {
let chrome = await chromeLauncher.launch({
port: 9222,
chromeFlags: ['--headless', '--disable-gpu']
});
console.log(`Chrome debugging port running on ${chrome.port} with pid ${chrome.pid}`);
return chrome;
}
catch(ex) {
console.error(ex.message);
}
};
async function run() {
try{
const chromeless = new Chromeless();
const screenshot = await chromeless
.goto('https://www.google.com')
.type('chromeless', 'input[name="q"]')
.press(13)
.wait('#resultStats')
.screenshot();
await chromeless.end();
return screenshot;
}
catch(ex) {
console.error(ex.message);
}
};
async function main() {
try {
let chrome = await launchHeadlessChrome();
let path = await run();
console.log(`Screenshot saved to ${path}`);
chrome.kill().catch(e => console.error(e));
}
catch(ex) {
console.error(ex.message);
}
};
main();
I started getting the following error:
Chrome debugging port running on 9222 with pid 7276
Screenshot saved to /tmp/cj5vimyfi000014l283dc8nal.png
(node:5224) UnhandledPromiseRejectionWarning: Unhandled promise rejection (rejection id: 1): Error: write ECONNRESET
(node:5224) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.
When I was working in a slow enviornment (i.e.) over VPN, the error occured less (1 in 3 times), which led me to try replacing the chrome.kill() line with this setTimeout(() => {chrome.kill().catch(e => console.error(e));}, 2000);. Adding the delay solved it 100% of the time, although this is definitely not the solution I want.
I believe the end() promise resolves before Chromeless fully disconnects from Chrome. Killing the instance causes a hard ECONNRESET, that is not handled. (Either that, or I'm doing something wrong in my code).
Thanks!
PS: BTW, I'm on Windows 10, if it makes any difference...
I'm seeing the same thing on MacOS Sierra/Chrome 60.0.3112.90 (Official Build) (64-bit)
Same here MacOS Version 60.0.3112.90 (Official Build) (64-bit)
@TravelingTechGuy was this issue resolved by v1.3.0?
Looks like it does!
Still running into this issue with the latest 1.3.0 version.
read ECONNRESET
I'm doing this after each test suite (using jest)
export function closeChrome(chrome) {
return new Promise((resolve, reject) => {
chrome.end().then(() => {
setTimeout(() => {
chrome.kill()
.then(() => resolve())
.catch(e => {
console.error(">>> error closing chrome", e);
reject(e);
});
}, 2500);
})
});
}
beforeAll((done) => {
chromeless = new Chromeless({
remote: true,
viewport: { width: 768, height: 1024 }
});
done();
})
afterAll(() => {
jest.setTimeout(3000);
return closeChrome(chromeless);
})
update: when I simply do chrome.end() in the afterAll, the error message is Error: connect ECONNREFUSED 127.0.0.1:9222
It's quite random. Sometimes tests pass but most of the time at least one would fail. So it's most likely an issue with the chrome instance not being ready or properly closed (though isn't chromeless supposed to create another instance on AWS lambda for each test suite? Why do we have to end the chrome connection?)
+1 @xdamman we're seeing similar on lambda, ~1-in-10 requests failing
+1
+1
+1
Having the same issue. Doing await chromeless.queue.end() in a catch block seems to work (taken from the source here).
Full example:
const { Chromeless } = require('chromeless')
const chromeless = new Chromeless({ waitTimeout: 5000 });
const twitterUsername = "xxx"
const twitterPassword = "xxx"
async function run() {
const screenshot = await chromeless
.goto('https://twitter.com/login/')
.type(twitterUsername, '.js-username-field')
.type(twitterPassword, '.js-password-field')
.click('button[type="submit"]')
.wait('.status')
.screenshot()
await chromeless.end()
}
run().catch(async (error) => {
console.log(error);
await chromeless.queue.end()
})
Without that the node process continues forever on an error...
Most helpful comment
+1 @xdamman we're seeing similar on lambda, ~1-in-10 requests failing