Me he estado topando con esto muy a menudo también. Parece que sucede con más frecuencia, quizás exclusivamente, cuando Chrome está en segundo plano. Podría ser solo una coincidencia

¡Sí, también recibí este feo error!

Disculpas por la respuesta tardía aquí; No he llegado a reproducir esto. ¿Podría alguno de ustedes proporcionar un pequeño repositorio de ejemplo (podría usar https://github.com/NickTomlin/protractor-mcve como iniciador) de una aplicación angular 2 que reproduzca esto?

Eliminar el flujo de control es un paso en la dirección correcta, pero puede estar revelando algunos problemas (como este) que tendremos que tener en cuenta. ¡Gracias!

@NickTomlin @wcainboundary Acabo de actualizar mi nodejs a la última versión estable y ahora funciona bien.

no funcionó:

$node -v
v6.10.1

Funciona bien:

$node -v
v7.10.0

Estoy viendo el error en el nodo v8.0.0

También veo este error _sin_ transportador (simplemente [email protected] y creo que 3.3 antes). Nunca sucede en OS X, pero con bastante frecuencia en nuestros agentes de compilación (Linux).

No he visto este problema presentado contra Selenium, pero probablemente debería serlo.

He visto este error en OSX.

Para mí, el problema estaba relacionado con el tiempo. Mi prueba estaba tratando de interactuar con un elemento que no estaba disponible. Aunque las tareas angulares se completaron, parte de la representación en la página no se completó, lo que provocó este problema. Era más fácil de reproducir en nuestra cuadrícula alojada ya que las conexiones eran más lentas.

Vi esto con waitForAngularEnabled establecido en verdadero y falso.

Antes de la actualización, solíamos tener errores de tiempo de espera en algunas de las mismas pruebas. Me pregunto si Webdriver 3.x solo dice lo mismo de una manera diferente...

+1 en esto, me encuentro con el mismo problema al ejecutar mis especificaciones localmente en OS X 10.12.5

Por lo que vale, era menos probable que viera el error EPIPE en:

• Nodo 7.10.1
• OS X 10.12.5
• Protactor 5.1.2
• cromo 59.0.3071.115

Y, cuando digo _menos probable_, me refiero a que cuando ejecuté mi suite 7 veces con mi configuración anterior, 4 de las ejecuciones fueron exitosas si enfoqué de inmediato mi navegador Chrome y no moví el mouse del ícono de la base de Chrome (probablemente no relacionado).

En nuestro proyecto, aparecían errores EPIPE , porque las pruebas (en TypeScript) usaban incorrectamente await s. Y, por lo tanto, los rechazos de Promesa no controlados ocurrían al azar y conducían a estos errores. Una vez que solucioné los usos incorrectos, ya no tenemos estos errores en el Nodo 8.

Intente revisar sus pruebas cuidadosamente para ver si hay usos incorrectos de await (ya sea que falten o sean redundantes) o simplemente un encadenamiento incorrecto de Promise (por ejemplo, cuando olvidó devolver Promise de los métodos auxiliares). En nuestro caso, el error típico fue usar:

browser.wait(await EC.invisibilityOf(fade)); // incorrect

en vez de:

await browser.wait(EC.invisibilityOf(fade)); // correct

Tal vez ayude a alguien que también tenga este problema.

¿Está solucionado este problema? Todavía lo veo con la versión de nodo 7.7.3 y la versión de transportador 5.1.1

@ sri1987 mira mi comentario anterior. Lo más probable es que sea un problema en su código, no en Protractor.

@ sri1987 Si no es reproducible consistentemente, definitivamente está relacionado con await faltantes/extra en alguna parte.

Recibí estos errores muy a menudo últimamente con SELENIUM_PROMISE_ MANAGER:false
Al ejecutar varias pruebas

El problema aquí y en #4507 parece ser los comandos webdriver concurrentes. @wvanderdeijl sugirió una solución para el caso particular de ElementArrayFinder::map() en #4508. Hasta que esto se resuelva correctamente, el siguiente contenedor para browser.driver.schedule() , que crea una cola para evitar que se ejecuten comandos webdriver simultáneos, podría ser una solución alternativa.

¿Puede alguien que esté experimentando errores EPIPE probar esto regularmente? Puede ralentizar la ejecución de la prueba hasta cierto punto.

El siguiente código se puede llamar en el gancho onPrepare() Protractor, por ejemplo.

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;
}

o con algún registro adicional:

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
Creo que estás en el lugar correcto allí. Reduje la mayoría de mis errores que provenían de funciones que devuelven una llamada Promise.all, así que estoy bastante seguro de que debe tener algo que ver con la concurrencia.

@renehamburger gracias. Después de agregar este a la sección onPrepare de mi protractor.conf.js:

let currentCommand = Promise.resolve();
// Serialise all webdriver commands to prevent EPIPE errors
const webdriverSchedule = browser.driver.schedule;
browser.driver.schedule = (command, description) => {
   currentCommand = currentCommand.then(() =>
      webdriverSchedule.call(browser.driver, command, description)
    );
    return currentCommand;
};

Error 'Error: EPIPE escribir EPIPE' desapareció.

@ Xaz16 : Funcionó para nosotros como solución, ¡gracias!

Pero el error "EPIPE escribe EPIPE" parece ser un error en Selenium: https://github.com/SeleniumHQ/selenium/issues/5345 que se resolverá en 4.0.0.

Entonces, tenemos que esperar hasta que Protractor use la versión 4.0.0 y podamos eliminar esta solución.

¿Tenemos algún enlace a la hoja de ruta de Protractor ? O no existe en absoluto

@renehamburger , ¿podrías ayudar? Intento volver a escribir su solución alternativa en caso de que SELENIUM_PROMISE_MANAGER: false . Actualmente, si solo copio/paso su solución, hay muchos problemas extraños que creo que podrían resolverse usando async/await .

@CrispusDH Tuve que cambiar el fragmento de código a

let currentCommand = Promise.resolve(); // Serialise all webdriver commands to prevent EPIPE errors const webdriverSchedule = browser.schedule; browser.schedule = (command, description) => { currentCommand = currentCommand.then(() => webdriverSchedule.call(browser, command, description) ); return currentCommand; };

Así que básicamente elimina el .driver

Usar Async/await parece ser un desastre mayor que controlFlow.

El error aún se observa en Mac OS Sierra incluso después de probar la solución anterior.

¿Hay alguna otra solución que pueda probar?

Gracias

En nuestro caso, parece ser un uso incorrecto de async/await en algunas afirmaciones.

tenía esto:

    const modal = await page.getModalInfo()
    expect(modal.isDisplayed()).toBeTruthy()

en vez de:

    const modal = page.getModalInfo()
    expect(await modal.isDisplayed()).toBeTruthy()

Hola , @danigar La función isDisplayed() devuelve la promesa, por lo que es esencial usar await si desea resolverlo. Entonces, su segunda línea de código en el segundo ejemplo se ve bien.
¿Qué pasa con await en su primera línea? Depende de qué devuelva getModalInfo() . No está claro en este punto y no puedo ver la conexión entre la primera y la segunda línea.

@marcincharezinski jasmine resolverá Promise en except() por ti mismo sin await .

Sí. Perdón por el retraso @marcincharezinski. El método getModalInfo() de la primera línea devolvió un ElementFinder (no envuelto en una Promesa), y como puede ver en el primer ejemplo, obtuvimos awaiting por ello.
Tuvimos algunos problemas como estos y una vez que los solucionamos, el error EPIPE desapareció 😊.

@CrispusDH : solía pensar lo mismo hasta que seguía teniendo problemas con las pruebas que fallaban por razones que no podía entender. Regresé y agregué await dentro de mis estados de cuenta except() y eso los aclaró.

@Mokkapps Al menos en TypeScript, su código da el error:
Escribe '(comando: Comando, descripción: cadena) => Promesa nula' no es asignable al tipo ' T (comando: Comando, descripción: cadena) => Promesa T'.
El tipo 'Promise void' no se puede asignar al tipo 'Promise T'.
Falta la propiedad 'cancelar' en el tipo 'Promesa nula'.

@kahan002

Finalmente lo resolvimos usando este código.

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;
    };
  }
}

que se llama en protractor.conf.ts

onPrepare: () => { patchSchedule(); },

Gracias @Mokkapps por compartir eso. Un par de apuntes por si alguien quiere adaptarlo para mecanografiado y un entorno como el mío. os.platform() no se conocía, así que usé process.platform . Tuve que import { Command } from "selenium-webdriver"; Tuve que comentar el ConcurrencyCounter ya que nunca se leyó. Y dado que tengo una advertencia de mecanografiado en cualquiera implícito, necesitaba hacerlos explícitos en .then((result : any) => { y .catch((error: any) => { . No me quejo del código y me alegro de que lo hayas compartido (parece solucionar el problema, aunque es un poco difícil saberlo porque era intermitente). Espero que este comentario sea útil para alguien. Muchas gracias por responderme a mí y a los demás.
Pero tal vez mis cambios rompieron su solución, porque acabo de recibir UnhandledPromiseRejectionWarning: Rechazo de promesa no manejado (id de rechazo: 4): Error: EPIPE escribe EPIPE
(nodo: 8514) [DEP0018] DeprecationWarning: los rechazos de promesa no controlados están en desuso. En el futuro, los rechazos de promesas que no se controlen terminarán el proceso de Node.js con un código de salida distinto de cero.
después de todo. Volveré y veré dónde debo estar usando mal await .

¿Algún progreso para los usuarios de OSX?

Creo que esto podría desencadenarse por la misma situación que otros errores similares, cuya solución es usar HTTP keep-alive en la comunicación entre el código de Selenium Node y el navegador. Hay una solución para esto en la línea principal de Selenium, el año pasado, pero no está publicada en ninguna versión de ese código.

Esta es la solución que usamos aquí, tomada prestada y editada de algo que otro comentarista escribió en otra edición. Configure un NPM package.script para ejecutarlo:

"scripts": {
    "install": "webdriver-manager update && node keep-alive-patch.js",

El código del parche es:

const fs = require('fs');
const chromeFile = 'node_modules/selenium-webdriver/chrome.js';
fs.readFile(chromeFile, 'utf8', function (err, data) {
  if (err)
    throw err;

  const result = data.replace(/new http.HttpClient\(url\)/g,
    "new http.HttpClient(url, new (require('http').Agent)({ keepAlive: true }))");
  console.log(`Patching ${chromeFile}`);
  fs.writeFileSync(chromeFile, result, 'utf8');
});

Con este parche, Protractor es 99% más robusto para nosotros tanto en Windows como en OSX, usando SELENIUM_PROMISE_MANAGER: false . Su millaje puede variar, dependiendo de si su error EPIPE es causado por la misma situación subyacente que la nuestra.

Encuentro que las esperas con cadenas (o sobre matrices) parecen más vulnerables. Entonces, por ejemplo, acabo de ver el error con let testFormatID: string =await element.all(by.className('ng-star-inserted')).all(by.tagName('td')).get(1). obtenerTexto(); Es posible que el error sea mío y que lo que he escrito no funcione.

#4792 parece haber solucionado mis problemas en Mac OS X. Gracias por el consejo, IgorDorokhov.

@ kahan002 ¡de nada!

¿Algún ETA para 4.0.0-alpha.1 incluido en el transportador?

4792 no solucionó el problema para mí. Sigo recibiendo Failed: EPIPE write EPIPE error 1 de 5 al filtrar en ElementArrayFinder:

$$('classified-section').filter((section) => section.isDisplayed())

Actualice a [email protected] . Ahí parece estar resuelto.

@demisx Lo parcheé aquí y me funciona

@rafalf Gracias. Si está hablando de "tomar index.js de selenium-3.7.0 y agregar ECONNREFUSED", lo intenté, pero todavía recibía este error ocasionalmente. Por favor, hágamelo saber si entendí mal su comentario.

El error EPIPE todavía ocurre con bastante frecuencia con el último transportador 5.4.1, chromedriver_2.43 y async/await en MacOS Mojave. Ya no podemos ejecutar especificaciones E2E en CI. Realice varias ejecuciones manuales hasta que todas pasen. muy inestable

@demisx
esto me sucede principalmente para each , filter y otras funciones que se usan con arreglos

cómo lo reelaboré

        // EPIPE write EPIPE
        // await $$("short-list-component.ng-valid mat-label").each(async function (element) {
        //     labels.push(await element.getText())
        // });
        // this.logInfo("getMatLabels: " + labels);
        // return labels

        let l = await $$("q-short-list-component.ng-valid mat-label");
        for (let element of l){
            text = await element.getText();
            labels.push(text)
        }

@rafalf Sí, eso fue lo primero de lo que nos deshicimos. Aunque redujo la frecuencia de los errores de EPIPE, estos no desaparecieron por completo. Está empeorando cuando se ejecuta un transportador con múltiples capacidades. Entonces, el parche @kylecordes parece estar haciendo el trabajo. ¡Gracias @kylecordes! Con suerte, esta solución llegará pronto a master .

Fuera de tema, no necesita await en let l = await $$("q-short-list-component.ng-valid mat-label") . El $$ devuelve ElementArrayFinder , no es una promesa. 😉

@demisx no, estás equivocado, tal vez por eso todavía obtienes errores de EPIPE: bailarín:
Sí, devuelve ElementArrayFinder sin espera, pero no podrá iterar sobre él.
y esta parte no funcionaría

for (let element of l){
            text = await element.getText();
            labels.push(text)
        }

si hago await , obtengo una lista de elementos;) que puedo revisar

@rafalf Lo siento, mi error. Me perdí la parte de iteración debajo de await . Tienes toda la razón.

Puede que me equivoque, pero parece que tales errores me ocurren de forma intermitente dondequiera que se use ElementArrayFinder de la siguiente manera:
await $$('some-selector').click()

@yyankowski Sí, también fue mi experiencia. Vi este error ocurriendo con $$ más que cualquier otra cosa. Especialmente, al intentar llamar a un método en el ElementArrayFinder devuelto por $$ .