chrome-launcher
chrome-launcher copied to clipboard
Occasional "No inspectable targets" error when launching chrome with a very short connectionPollInterval
To reproduce, create and run a Node script such as the one below:
const chromeLauncher = require('chrome-launcher');
const CDP = require('chrome-remote-interface');
let opts = {
connectionPollInterval: 2,
chromeFlags: ['--headless'],
};
(async() => {
for (let i = 0; i < 100; i++) {
let chrome = await chromeLauncher.launch(opts);
let client = await CDP({port: chrome.port});
console.log(i, chrome.port);
client.close();
chrome.kill();
}
})().catch(error => {
console.log(error);
process.exit(1)
});
After an unpredictable number of loops, the script (usually) crashes with a stacktrace:
Error: No inspectable targets
at defaultTarget (.../node_modules/chrome-remote-interface/lib/chrome.js:47:23)
at Chrome._fetchDebuggerURL (.../node_modules/chrome-remote-interface/lib/chrome.js:188:32)
at process.internalTickCallback (internal/process/next_tick.js:77:7)
It looks like chrome-launcher
occasionally reports that the launched Chrome instance is ready and has a debugging port, even though it isn't actually ready to accept a debug session yet.
Thanks very much for filing with a simple repro case!
That's correct chrome-launcher
resolves as soon as Chrome has begun listening on the debugging port and not necessarily when a target/the requested launch page is available for inspection.
If you'd be interested in adding this functionality to chrome-launcher, I'd bet some other folks might end up making use of it as well :)
I imagine it just might involve polling http://127.0.0.1:<port>/json/list
until it has an entry if you wanted to do it yourself.
@patrickhulce It's great to get such a fast response!
But I'm a little unsure of what you're suggesting. Do you consider the issue I reported to be a bug or normal/expected behavior? In the latter case, would adding a flag (e.g. waitForInspectableTarget
) to the launch options be an acceptable solution, or do you have something else in mind?
Do you consider the issue I reported to be a bug or normal/expected behavior?
I consider it to be expected behavior, but I understand your use case is a common one that could be worthwhile to support in the library (waitForInspectableTarget
sounds great to me 👍 ).