New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Failed: EPIPE write EPIPE frequently seen when SELENIUM_PROMISE_MANAGER: false #4294
Comments
I've been bumping into this quite often as well. It seems like it happens more often, maybe exclusively, when Chrome is in the background. Might just be a coincidence |
Yes I got this ugly error too! |
Apologies for the late response here; I haven't gotten around to reproducing this. Could one of you provide a small example repo (you could use https://github.com/NickTomlin/protractor-mcve as a starter) of an angular 2 app that reproduces this? Removing the control flow is a step in the right direction but it may be revealing some issues (like this one) that we will need to account for. Thanks! |
@NickTomlin @wcainboundary I just upgraded my nodejs to the latest stable version and it works fine now. Didn't work:
Works fine:
|
I am seeing the error in node v8.0.0 |
I'm also seeing this error without protractor (straight webdriver.js@3.4 and I believe 3.3 before it). Never happens on OS X, but quite frequently on our build agents (Linux). I haven't seen this issue filed against Selenium, but it probably should be. |
I have seen this error in OSX. For me the issue was timing related. My test was trying to interact with an element that was not available. Although the angular tasks were complete some rendering on the page was not complete which led to this issue. It was easier to reproduce on our hosted grid since the connections were slower. I did see this with waitForAngularEnabled set to true and false. |
Prior to upgrading, we used to get timeout errors on some of the same tests. I wonder if Webdriver 3.x is just saying the same thing a different way... |
+1 on this, running into the same issue when running my specs locally on OS X 10.12.5 |
For what it's worth, I was less likely to see the EPIPE error on:
And, when I say less likely, I mean that when I ran my suite 7 times with my above configuration, 4 of the runs were successful if I immediately focused my Chrome browser and didn't move my mouse from the Chrome dock icon (probably not related). |
In our project Try to check your tests carefully for incorrect usages of
instead of:
Maybe it will help somebody, who also has this issue. |
Is this issue fixed ? I still see it with node version 7.7.3 and protractor version 5.1.1 |
@sri1987 see my comment above. It's most likely issue in your code, not in Protractor. |
@sri1987 If it's not reproducible consistently it's definitely related to missing/extra |
Got these error very often lately with SELENIUM_PROMISE_MANAGER:false |
The issue here and in #4507 seems to be concurrent webdriver commands. @wvanderdeijl suggested a solution for the particular case of Can someone who's experiencing EPIPE-errors regularly test this? It may slow down the test execution to some degree. The following code can be called in Protractor's let currentCommand = Promise.resolve();
// Serialise all webdriver commands to prevent EPIPE errors
const webdriverSchedule = browser.driver.schedule;
browser.driver.schedule = (command: Command, description: string) => {
currentCommand = currentCommand.then(() =>
webdriverSchedule.call(browser.driver, command, description)
);
return currentCommand as any;
} or with some additional logging: let currentCommand = Promise.resolve();
let concurrencyCounter = 0;
// Serialise all webdriver commands to prevent EPIPE errors
const webdriverSchedule = browser.driver.schedule;
browser.driver.schedule = (command: Command, description: string) => {
console.log(`${++concurrencyCounter} concurrent webdriver command(s). Latest command: ${description}`);
currentCommand = currentCommand.then(() =>
webdriverSchedule.call(browser.driver, command, description)
.then(result => {
concurrencyCounter--;
return result;
})
.catch(error => {
concurrencyCounter--;
//console.lgErrLabel('Webdriver error')(command, description, error);
console.error('Webdriver error:', command, description, error);
throw error;
})
);
return currentCommand as any;
} |
@renehamburger |
@renehamburger thank you. After add this one to onPrepare section of my protractor.conf.js:
Error 'Failed: EPIPE write EPIPE' is gone. |
@Xaz16: Worked for us as workaround, thanks! But the "EPIPE write EPIPE" erroms seems to be a bug in Selenium: SeleniumHQ/selenium#5345 which will be solved in 4.0.0. So we have to wait until Protractor uses 4.0.0 version and the we can remove this workaround. |
Do we have some link to |
@renehamburger , could you help? I try to re-write your workaround in case when |
@CrispusDH I had to change the code snippet to
So basically remove the |
Using Async/await seems to be a bigger mess than the controlFlow. The error is still observed on Mac OS Sierra even after trying the above solution. Is there any other solution that can try. Thanks |
In our case seems to be a wrong use of async/await in some assertions. had this:
instead of:
|
Hi @danigar Function |
@marcincharezinski |
Yep. Sorry for the delay @marcincharezinski. The |
@CrispusDH - I used to think the same thing until I kept getting issues around tests failing for reasons I couldn't understand. I went back and added |
@Mokkapps At least in TypeScript your code gives the error: |
We finally solved it using this code function patchSchedule() {
if (os.platform() === 'darwin') {
let currentCommand = Promise.resolve();
let concurrencyCounter = 0;
// Serialise all webdriver commands to prevent EPIPE errors
const webdriverSchedule = browser.driver.schedule;
browser.driver.schedule = (command: Command, description: string) => {
currentCommand = currentCommand.then(() =>
webdriverSchedule
.call(browser.driver, command, description)
.then(result => {
concurrencyCounter--;
return result;
})
.catch(error => {
concurrencyCounter--;
// tslint:disable-next-line:no-console
console.error('Webdriver error:', command, description, error);
throw error;
})
);
return currentCommand as any;
};
}
} which is called in protractor.conf.ts
|
Thanks @Mokkapps for sharing that. A couple of notes in case someone wants to adapt it for typeScript and an environment like mine. |
Any progress for OSX users? |
I think this might be triggered by the same situation as some other similar errors, the fix for which is to use HTTP keep-alive in the communication between the Selenium Node code and the browser. There is a fix for this in the Selenium mainline, last year - but it is not published in any version of that code. Here is the workaround we use here, borrowed and edited from something another commenter wrote in another issue. Set up a NPM package.script to run it:
The patcher code is:
With this patch, Protractor is 99%+ robust for us on both Windows and OSX, using |
I find that awaits with chains (or over arrays) seem most vulnerable. So for instance I just saw the error with let testFormatID: string =await element.all(by.className('ng-star-inserted')).all(by.tagName('td')).get(1).getText(); It is possible that the error is mine and that what I have written should not work. |
#4792 seems to have fixed my issues on Mac OS X. Thanks for the tip, IgorDorokhov . |
@kahan002 you are welcome! |
any ETA for 4.0.0-alpha.1 included in protractor? |
#4792 did not fix the problem for me. Still getting $$('classified-section').filter((section) => section.isDisplayed()) Please upgrade to |
The EPIPE error still happens quite often with latest protractor 5.4.1, chromedriver_2.43 and async/await on MacOS Mojave. We can't run E2E specs on CI anymore. Take multiple manual runs until all of them pass. Very unstable. |
@demisx how I reworked it
|
@rafalf Yeah, that was the first thing we got rid of. Though, it reduced the frequency of EPIPE errors, they did not go away completely. It's getting worse when running protractor with multiple capabilities. So, far @kylecordes patch seems to be doing the job. Thank you @kylecordes! Hopefully, this fix will make it to Off topic, you don't need |
@demisx no you are wrong , maybe thats why you get still EPIPE errors 💃
if i do |
@rafalf Sorry, my bad. I missed the iteration part below the |
I may be mistaken but it looks like such errors intermittently happen for me wherever there is a usage of ElementArrayFinder in the following way: |
@yyankowski Yes, it was my experience as well. I saw this error happening with |
Bug report
6.9.1
5.1.2
4.0.0
Chrome Version 57.0.2987.133 (64-bit)
OS X Version 10.10.5 (14F2315)
Also excerpt from npm-debug.log:
SELENIUM_PROMISE_MANAGER: false
in config (disable control flow).Failed: EPIPE write EPIPE
errors unpredictably.I'm not using await. I cannot identify any unhandled promises in the test code either (and I'm experienced with promises), although that has been suggested in some of the comments, so I have to allow for that possibility. Still, it's surprising that node would crash on an unhandled promise, if that's the case. So it seems there's a node bug in here somewhere, in addition to whatever problem there may be in my test or protractor or webdriver, etc.
Sorry, it's not public.
The text was updated successfully, but these errors were encountered: