Darüber bin ich auch schon oft gestolpert. Es scheint, als ob es häufiger, vielleicht ausschließlich, passiert, wenn Chrome im Hintergrund läuft. Kann nur ein Zufall sein

Ja, ich habe auch diesen hässlichen Fehler!

Entschuldigung für die späte Antwort hier; Ich bin noch nicht dazu gekommen, das zu reproduzieren. Könnte einer von Ihnen ein kleines Beispiel-Repo (Sie könnten https://github.com/NickTomlin/protractor-mcve als Starter verwenden) einer Winkel-2-App bereitstellen, die dies reproduziert?

Das Entfernen des Kontrollflusses ist ein Schritt in die richtige Richtung, aber es kann einige Probleme (wie dieses) aufdecken, die wir berücksichtigen müssen. Danke!

@NickTomlin @wcainboundary Ich habe gerade meine nodejs auf die neueste stabile Version aktualisiert und es funktioniert jetzt gut.

Hat nicht funktioniert:

$node -v
v6.10.1

Funktioniert gut:

$node -v
v7.10.0

Ich sehe den Fehler im Knoten v8.0.0

Ich sehe auch diesen Fehler _ohne_ Winkelmesser (gerade [email protected] und ich glaube 3.3 davor). Unter OS X passiert das nie, aber ziemlich häufig unter unseren Build-Agenten (Linux).

Ich habe nicht gesehen, dass dieses Problem gegen Selenium eingereicht wurde, aber es sollte wahrscheinlich sein.

Ich habe diesen Fehler in OSX gesehen.

Für mich war das Problem zeitlich bedingt. Mein Test versuchte, mit einem Element zu interagieren, das nicht verfügbar war. Obwohl die eckigen Aufgaben abgeschlossen waren, waren einige Renderings auf der Seite nicht abgeschlossen, was zu diesem Problem führte. Es war einfacher, es auf unserem gehosteten Grid zu reproduzieren, da die Verbindungen langsamer waren.

Ich habe dies gesehen, als waitForAngularEnabled auf true und false gesetzt war.

Vor dem Upgrade traten bei einigen der gleichen Tests Zeitüberschreitungsfehler auf. Ich frage mich, ob Webdriver 3.x dasselbe nur anders sagt ...

+1 dazu, bei der lokalen Ausführung meiner Spezifikationen unter OS X 10.12.5 tritt dasselbe Problem auf

Für das, was es wert ist, war es weniger wahrscheinlich, dass ich den EPIPE-Fehler auf:

• Knoten 7.10.1
• OS X 10.12.5
• Protektor 5.1.2
• Chrom 59.0.3071.115

Und wenn ich _weniger wahrscheinlich_ sage, meine ich, dass, als ich meine Suite 7 Mal mit meiner obigen Konfiguration ausgeführt habe, 4 der Läufe erfolgreich waren, wenn ich sofort meinen Chrome-Browser fokussierte und meine Maus nicht vom Chrome-Dock-Symbol bewegte (wahrscheinlich nicht verwandten).

In unserem Projekt EPIPE traten Fehler auf, weil Tests (in TypeScript) fälschlicherweise await s verwendeten. Und daher kam es zufällig zu unbehandelten Versprechensablehnungen, die zu diesen Fehlern führten. Sobald ich falsche Verwendungen behoben habe, treten diese Fehler auf Knoten 8 nicht mehr auf.

Versuchen Sie, Ihre Tests sorgfältig auf falsche Verwendungen von await (entweder fehlend oder überflüssig) oder einfach auf falsche Promise-Verkettung zu überprüfen (z. B. wenn Sie vergessen haben, Promise von Hilfsmethoden zurückzugeben). In unserem Fall war ein typischer Fehler die Verwendung von:

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

anstatt:

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

Vielleicht hilft es jemandem, der auch dieses Problem hat.

Ist dieses Problem behoben? Ich sehe es immer noch mit der Knotenversion 7.7.3 und der Winkelmesserversion 5.1.1

@ sri1987 siehe meinen Kommentar oben. Es ist höchstwahrscheinlich ein Problem in Ihrem Code, nicht in Protractor.

@sri1987 Wenn es nicht konsistent reproduzierbar ist, hängt es definitiv mit fehlenden/zusätzlichen await irgendwo zusammen.

Bekam diesen Fehler in letzter Zeit sehr oft mit SELENIUM_PROMISE_ MANAGER:false
Beim Ausführen mehrerer Tests

Das Problem hier und in #4507 scheinen gleichzeitige Webdriver-Befehle zu sein. @wvanderdeijl schlug eine Lösung für den speziellen Fall von ElementArrayFinder::map() in #4508 vor. Bis dies ordnungsgemäß gelöst ist, könnte der folgende Wrapper für browser.driver.schedule() , der eine Warteschlange erstellt, um zu verhindern, dass gleichzeitige Webdriver-Befehle ausgeführt werden, eine Problemumgehung darstellen.

Kann jemand, der regelmäßig EPIPE-Fehler hat, dies testen? Dies kann die Testausführung bis zu einem gewissen Grad verlangsamen.

Der folgende Code kann beispielsweise im Hook onPrepare() Protractor aufgerufen werden.

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

oder mit zusätzlicher Protokollierung:

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
Ich denke, da bist du genau richtig. Ich habe eingegrenzt, dass die meisten meiner Fehler von Funktionen stammen, die einen Promise.all-Aufruf zurückgeben, also bin ich mir ziemlich sicher, dass es etwas mit Parallelität zu tun haben muss

@renehamburger danke. Nachdem Sie diese zum Abschnitt onPrepare meiner protractor.conf.js hinzugefügt haben:

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

Fehler „Fehlgeschlagen: EPIPE schreiben EPIPE“ ist weg.

@Xaz16 : Hat für uns als Problemumgehung funktioniert, danke!

Aber der "EPIPE write EPIPE"-Fehler scheint ein Fehler in Selenium zu sein: https://github.com/SeleniumHQ/selenium/issues/5345 , der in 4.0.0 behoben wird.

Wir müssen also warten, bis Protractor die Version 4.0.0 verwendet und wir diese Problemumgehung entfernen können.

Haben wir einen Link zur Protractor -Roadmap? Oder es existiert gar nicht

@renehamburger , kannst du helfen? Ich versuche, Ihre Problemumgehung neu zu schreiben, falls SELENIUM_PROMISE_MANAGER: false . Wenn ich Ihre Lösung derzeit einfach kopiere/einfüge, gibt es viele seltsame Probleme, die meiner Meinung nach mit async/await gelöst werden könnten.

@CrispusDH Ich musste das Code-Snippet ändern

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

Entfernen Sie also im Grunde das .driver

Die Verwendung von Async/await scheint ein größeres Durcheinander zu sein als der ControlFlow.

Der Fehler wird unter Mac OS Sierra auch nach dem Versuch der obigen Lösung weiterhin beobachtet.

Gibt es eine andere Lösung, die Sie versuchen können.

Danke

In unserem Fall scheint es sich um eine falsche Verwendung von async/await in einigen Behauptungen zu handeln.

hatte das:

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

anstatt:

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

Hallo @danigar Die Funktion isDisplayed() gibt das Versprechen zurück, daher ist es wichtig, await zu verwenden, wenn Sie es lösen möchten. Ihre zweite Codezeile im zweiten Beispiel sieht also gut aus.
Was ist mit await in Ihrer ersten Zeile, es hängt davon ab, was getModalInfo() . Es ist an dieser Stelle unklar und ich kann keine Verbindung zwischen der 1. und 2. Zeile erkennen.

@marcincharezinski jasmine wird Promise in except() selbst ohne await auflösen.

Ja. Sorry für die Verspätung @marcincharezinski. Die getModalInfo() -Methode der ersten Zeile gab einen ElementFinder zurück (nicht in ein Promise eingeschlossen), und wie Sie im ersten Beispiel sehen, waren wir awaiting dafür.
Wir hatten einige Probleme wie diese und sobald wir sie behoben hatten, verschwand der EPIPE-Fehler 😊.

@CrispusDH - Früher dachte ich dasselbe, bis ich immer wieder Probleme mit fehlgeschlagenen Tests aus Gründen bekam, die ich nicht verstehen konnte. Ich ging zurück und fügte await in meine except() -Anweisungen ein und das klärte sie auf.

@Mokkapps Zumindest in TypeScript gibt Ihr Code den Fehler aus:
Typ '(command: Command, description: string) => Promise void' ist dem Typ 'T' nicht zuweisbar (command: Command, description: string) => Promise T'.
Der Typ „Promise void“ ist dem Typ „Promise T“ nicht zuordenbar.
Property 'cancel' fehlt im Typ 'Promise void'.

@kahan002

Wir haben es endlich mit diesem Code gelöst

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

die in protractor.conf.ts aufgerufen wird

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

Danke @Mokkapps , dass du das geteilt hast. Ein paar Anmerkungen für den Fall, dass jemand es für TypeScript und eine Umgebung wie meine anpassen möchte. os.platform() war nicht bekannt, also habe ich process.platform verwendet. Ich musste import { Command } from "selenium-webdriver"; Ich musste den concurrencyCounter auskommentieren, da er nie gelesen wurde. Und da ich eine TypeScript-Warnung für implizite habe, musste ich sie in .then((result : any) => { und .catch((error: any) => { explizit machen. Ich beschwere mich nicht über den Code, und ich freue mich, dass Sie ihn geteilt haben (er scheint das Problem zu beheben, obwohl es etwas schwer zu sagen ist, da er zeitweise aufgetreten ist). Ich hoffe, dass dieser Kommentar für jemanden hilfreich ist. Vielen Dank, dass Sie sich bei mir und anderen gemeldet haben.
Aber vielleicht haben meine Änderungen Ihre Lösung gebrochen, weil ich gerade UnhandledPromiseRejectionWarning erhalten habe: Unhandled Promise Rejection (Rejection ID: 4): Error: EPIPE write EPIPE
(node:8514) [DEP0018] DeprecationWarning: Unbehandelte Zurückweisungen von Promises sind veraltet. Zukünftig werden nicht verarbeitete Promise-Ablehnungen den Node.js-Prozess mit einem Exit-Code ungleich Null beenden.
schließlich. Ich werde zurückgehen und sehen, wo ich await missbrauchen muss.

Irgendwelche Fortschritte für OSX-Benutzer?

Ich denke, dies könnte durch die gleiche Situation ausgelöst werden wie einige andere ähnliche Fehler, deren Lösung darin besteht, HTTP-Keep-Alive in der Kommunikation zwischen dem Selenium-Knotencode und dem Browser zu verwenden. Es gibt dafür letztes Jahr eine Lösung in der Selenium-Hauptlinie - aber sie ist in keiner Version dieses Codes veröffentlicht.

Hier ist die Problemumgehung, die wir hier verwenden, geliehen und bearbeitet von etwas, das ein anderer Kommentator in einer anderen Ausgabe geschrieben hat. Richten Sie ein NPM-package.script ein, um es auszuführen:

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

Der Patchcode lautet:

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

Mit diesem Patch ist Protractor für uns sowohl unter Windows als auch unter OSX zu über 99 % robust und verwendet SELENIUM_PROMISE_MANAGER: false . Ihre Laufleistung kann variieren, je nachdem, ob Ihr EPIPE-Fehler durch die gleiche zugrunde liegende Situation wie bei uns verursacht wird.

Ich finde, dass Wartezeiten mit Ketten (oder über Arrays) am anfälligsten zu sein scheinen. So habe ich zum Beispiel gerade den Fehler mit let testFormatID gesehen: string =await element.all(by.className('ng-star-inserted')).all(by.tagName('td')).get(1). getText(); Es ist möglich, dass der Fehler von mir stammt und das, was ich geschrieben habe, nicht funktionieren sollte.

#4792 scheint meine Probleme unter Mac OS X behoben zu haben. Danke für den Tipp, IgorDorokhov .

@kahan002 du bist willkommen!

jede ETA für 4.0.0-alpha.1 im Winkelmesser enthalten?

4792 hat das Problem bei mir nicht behoben. Immer noch Failed: EPIPE write EPIPE Fehler 1 von 5 beim Filtern auf ElementArrayFinder:

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

Bitte führen Sie ein Upgrade auf [email protected] durch. Dort scheint es gelöst zu sein.

@demisx Ich habe es hier gepatcht und es funktioniert für mich

@rafalf Danke. Wenn Sie davon sprechen, "die index.js von Selenium-3.7.0 zu nehmen und ECONNREFUSED hinzuzufügen", dann habe ich das versucht, habe aber gelegentlich immer noch diesen Fehler erhalten. Bitte lassen Sie mich wissen, wenn ich Ihren Kommentar falsch verstanden habe.

Der EPIPE-Fehler tritt immer noch ziemlich oft mit dem neuesten Winkelmesser 5.4.1, chromedriver_2.43 und async/await auf MacOS Mojave auf. Wir können keine E2E-Spezifikationen mehr auf CI ausführen. Führen Sie mehrere manuelle Läufe durch, bis alle bestanden sind. Sehr instabil.

@demisx
das passiert mir hauptsächlich für each , filter und andere Funktionen, die mit Arrays verwendet werden

wie ich es nachgearbeitet habe

        // 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 Ja, das war das erste, was wir losgeworden sind. Es verringerte zwar die Häufigkeit von EPIPE-Fehlern, sie verschwanden jedoch nicht vollständig. Es wird schlimmer, wenn ein Winkelmesser mit mehreren Funktionen ausgeführt wird. Also, weit @kylecordes Patch scheint den Job zu machen. Danke @kylecordes! Hoffentlich schafft es dieser Fix bald auf master .

Off-Topic, Sie brauchen await nicht in let l = await $$("q-short-list-component.ng-valid mat-label") . $$ gibt ElementArrayFinder zurück, kein Versprechen. 😉

@demisx nein, du liegst falsch, vielleicht bekommst du deshalb immer noch EPIPE-Fehler :dancer:
Ja - es gibt ElementArrayFinder ohne Wartezeit zurück, aber Sie können nicht darüber iterieren
und dieser Teil würde nicht funktionieren

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

Wenn ich await mache, bekomme ich eine Liste von Elementen ;) die ich durchgehen kann

@rafalf Entschuldigung, mein Fehler. Ich habe den Iterationsteil unter dem await verpasst. Sie haben absolut Recht.

Ich kann mich irren, aber es sieht so aus, als ob solche Fehler bei mir zeitweise auftreten, wo immer ElementArrayFinder auf folgende Weise verwendet wird:
await $$('some-selector').click()

@yyankowski Ja, das war auch meine Erfahrung. Ich habe diesen Fehler häufiger bei $$ gesehen als bei allem anderen. Besonders wenn Sie versuchen, eine Methode für ElementArrayFinder aufzurufen, die von $$ zurückgegeben wird.