Je me suis également souvent heurté à cela. Il semble que cela se produise plus souvent, peut-être exclusivement, lorsque Chrome est en arrière-plan. Peut-être juste une coïncidence

Oui, j'ai eu cette vilaine erreur aussi!

Toutes mes excuses pour la réponse tardive ici ; Je n'ai pas eu le temps de reproduire cela. L'un d'entre vous pourrait-il fournir un petit exemple de dépôt (vous pourriez utiliser https://github.com/NickTomlin/protractor-mcve comme entrée) d'une application angular 2 qui reproduit cela ?

La suppression du flux de contrôle est un pas dans la bonne direction, mais cela peut révéler certains problèmes (comme celui-ci) dont nous devrons tenir compte. Merci!

@NickTomlin @wcainboundary Je viens de mettre à jour mon nodejs vers la dernière version stable et cela fonctionne bien maintenant.

N'a pas fonctionné :

$node -v
v6.10.1

Fonctionne bien :

$node -v
v7.10.0

Je vois l'erreur dans le nœud v8.0.0

Je vois également cette erreur _sans_ rapporteur ([email protected] et je crois 3.3 avant). N'arrive jamais sur OS X, mais assez fréquemment sur nos agents de build (Linux).

Je n'ai pas vu ce problème déposé contre Selenium, mais il devrait probablement l'être.

J'ai vu cette erreur dans OSX.

Pour moi, le problème était lié au timing. Mon test essayait d'interagir avec un élément qui n'était pas disponible. Bien que les tâches angulaires aient été terminées, certains rendus sur la page n'étaient pas complets, ce qui a conduit à ce problème. C'était plus facile à reproduire sur notre grille hébergée puisque les connexions étaient plus lentes.

J'ai vu cela avec waitForAngularEnabled défini sur true et false.

Avant la mise à niveau, nous avions l'habitude d'obtenir des erreurs de délai d'attente sur certains des mêmes tests. Je me demande si Webdriver 3.x dit simplement la même chose d'une manière différente ...

+1 à ce sujet, rencontrant le même problème lors de l'exécution de mes spécifications localement sur OS X 10.12.5

Pour ce que ça vaut, j'étais moins susceptible de voir l'erreur EPIPE sur :

• Nœud 7.10.1
• OSX 10.12.5
• Rapporteur 5.1.2
• Chromé 59.0.3071.115

Et, quand je dis _moins probable_, je veux dire que lorsque j'ai exécuté ma suite 7 fois avec ma configuration ci-dessus, 4 des exécutions ont réussi si je concentrais immédiatement mon navigateur Chrome et ne déplaçais pas ma souris de l'icône du dock Chrome (probablement pas de lien).

Dans notre projet, des erreurs EPIPE apparaissaient, car les tests (en TypeScript) utilisaient incorrectement await s. Et par conséquent, les rejets de Promise non gérés se produisaient de manière aléatoire et entraînaient ces erreurs. Une fois que j'ai corrigé les utilisations incorrectes, nous n'avons plus ces erreurs sur le nœud 8.

Essayez de vérifier attentivement vos tests pour détecter les utilisations incorrectes de await (manquantes ou redondantes) ou simplement un chaînage incorrect de Promise (par exemple, lorsque vous avez oublié de renvoyer Promise à partir des méthodes d'assistance). Dans notre cas, l'erreur typique consistait à utiliser :

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

à la place de:

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

Peut-être que cela aidera quelqu'un qui a aussi ce problème.

Ce problème est-il résolu ? Je le vois toujours avec la version de nœud 7.7.3 et la version de rapporteur 5.1.1

@ sri1987 voir mon commentaire ci-dessus. C'est probablement un problème dans votre code, pas dans Protractor.

@ sri1987 S'il n'est pas reproductible de manière cohérente, il est certainement lié à un await manquant/supplémentaire quelque part.

J'ai eu ces erreurs très souvent ces derniers temps avec SELENIUM_PROMISE_ MANAGER : false
Lors de l'exécution de plusieurs tests

Le problème ici et dans # 4507 semble être des commandes webdriver simultanées. @wvanderdeijl a suggéré une solution pour le cas particulier de ElementArrayFinder::map() dans #4508. Jusqu'à ce que cela soit résolu correctement, le wrapper suivant pour browser.driver.schedule() , qui crée une file d'attente pour empêcher l'exécution simultanée de commandes webdriver, peut être une solution de contournement.

Quelqu'un qui rencontre régulièrement des erreurs EPIPE peut-il tester cela? Cela peut ralentir l'exécution du test dans une certaine mesure.

Le code suivant peut être appelé dans le hook onPrepare() de Protractor, par exemple.

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

ou avec une journalisation supplémentaire :

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
Je pense que tu es sur la bonne voie. J'ai précisé que la plupart de mes erreurs provenaient de fonctions qui renvoient un appel Promise.all, donc je suis sûr que cela doit avoir quelque chose à voir avec la concurrence

@renehamburger merci. Après avoir ajouté celui-ci à la section onPrepare de mon 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;
};

L'erreur 'Échec : EPIPE écrit EPIPE' a disparu.

@Xaz16 : A travaillé pour nous comme solution de contournement, merci !

Mais l'erreur "EPIPE write EPIPE" semble être un bogue dans Selenium : https://github.com/SeleniumHQ/selenium/issues/5345 qui sera résolu en 4.0.0.

Nous devons donc attendre que Protractor utilise la version 4.0.0 et que nous puissions supprimer cette solution de contournement.

Avons-nous un lien vers la feuille de route Protractor ? Ou ça n'existe pas du tout

@renehamburger , pourriez-vous aider ? J'essaie de réécrire votre solution de contournement au cas où SELENIUM_PROMISE_MANAGER: false . Actuellement, si je copie/colle simplement votre solution, il y a beaucoup de problèmes étranges qui, à mon avis, pourraient être résolus en utilisant async/await .

@CrispusDH J'ai dû changer l'extrait de code en

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

Donc, en gros, supprimez le .driver

L'utilisation d'Async/wait semble être un plus gros gâchis que le controlFlow.

L'erreur est toujours observée sur Mac OS Sierra même après avoir essayé la solution ci-dessus.

Existe-t-il une autre solution qui peut essayer.

Merci

Dans notre cas, il semble y avoir une mauvaise utilisation de async/wait dans certaines assertions.

avait ça :

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

à la place de:

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

Salut @danigar La fonction isDisplayed() renvoie la promesse, il est donc essentiel d'utiliser l'attente si vous voulez le résoudre. Donc, votre deuxième ligne de code dans le deuxième exemple semble bien.
Qu'en est-il de await dans votre première ligne, cela dépend du retour getModalInfo() . Ce n'est pas clair à ce stade et je ne vois pas de lien entre les 1ère et 2ème lignes.

@marcincharezinski jasmine résoudra Promise en except() par vous-même sans await .

Ouais. Désolé pour le retard @marcincharezinski. La méthode getModalInfo() de la première ligne a renvoyé un ElementFinder (non enveloppé dans une Promise), et comme vous le voyez dans le premier exemple, nous étions awaiting pour cela.
Nous avons eu des problèmes comme ceux-ci et une fois que nous les avons corrigés, l'erreur EPIPE a disparu 😊.

@CrispusDH - J'avais l'habitude de penser la même chose jusqu'à ce que je continue à avoir des problèmes d'échec de tests pour des raisons que je ne comprenais pas. Je suis retourné et j'ai ajouté await dans mes relevés except() et cela les a clarifiés.

@Mokkapps Au moins dans TypeScript, votre code donne l'erreur :
Taper '(commande : Commande, description : chaîne) => Promise void' n'est pas assignable au type ' T (commande : Commande, description : chaîne) => Promise T'.
Le type 'Promise void' n'est pas attribuable au type 'Promise T'.
La propriété 'cancel' est manquante dans le type 'Promise void'.

@ kahan002

Nous l'avons finalement résolu en utilisant ce 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;
    };
  }
}

qui est appelé dans protractor.conf.ts

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

Merci @Mokkapps pour le partage. Quelques notes au cas où quelqu'un voudrait l'adapter à TypeScript et à un environnement comme le mien. os.platform() n'était pas connu, j'ai donc utilisé process.platform . J'ai dû import { Command } from "selenium-webdriver"; j'ai dû commenter le concurrencyCounter car il n'a jamais été lu. Et comme j'ai un avertissement typeScript sur tout implicite, je devais les rendre explicites dans .then((result : any) => { et .catch((error: any) => { . Je ne me plains pas du code, et je suis heureux que vous l'ayez partagé (il semble résoudre le problème, bien que ce soit un peu difficile à dire car il était intermittent). J'espère que ce commentaire est utile à quelqu'un. Merci beaucoup d'avoir répondu à moi et aux autres.
Mais peut-être que mes modifications ont cassé votre correctif, car je viens de recevoir UnhandledPromiseRejectionWarning : Rejet de la promesse non gérée (identifiant de rejet : 4) : Erreur : EPIPE write EPIPE
(node:8514) [DEP0018] DeprecationWarning : les rejets de promesses non gérées sont obsolètes. À l'avenir, les rejets de promesses qui ne sont pas gérés mettront fin au processus Node.js avec un code de sortie différent de zéro.
après tout. Je vais revenir en arrière et voir où je dois abuser await .

Des progrès pour les utilisateurs d'OSX ?

Je pense que cela pourrait être déclenché par la même situation que d'autres erreurs similaires, dont le correctif consiste à utiliser HTTP keep-alive dans la communication entre le code Selenium Node et le navigateur. Il existe un correctif pour cela dans la ligne principale de Selenium, l'année dernière - mais il n'est publié dans aucune version de ce code.

Voici la solution de contournement que nous utilisons ici, empruntée et modifiée à partir de quelque chose qu'un autre commentateur a écrit dans un autre numéro. Configurez un package NPM.script pour l'exécuter :

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

Le code du patcher est :

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

Avec ce correctif, Protractor est 99% + robuste pour nous sur Windows et OSX, en utilisant SELENIUM_PROMISE_MANAGER: false . Votre kilométrage peut varier, selon que votre erreur EPIPE est causée par la même situation sous-jacente que la nôtre.

Je trouve que les attentes avec des chaînes (ou sur des tableaux) semblent les plus vulnérables. Ainsi, par exemple, je viens de voir l'erreur avec let testFormatID: string =wait element.all(by.className('ng-star-inserted')).all(by.tagName('td')).get(1). getText(); Il est possible que l'erreur soit de moi et que ce que j'ai écrit ne fonctionne pas.

#4792 semble avoir résolu mes problèmes sur Mac OS X. Merci pour le tuyau, IgorDorokhov .

@kahan002 vous êtes les bienvenus !

un ETA pour 4.0.0-alpha.1 inclus dans le rapporteur ?

4792 n'a pas résolu le problème pour moi. Toujours obtenir Failed: EPIPE write EPIPE erreur 1 sur 5 lors du filtrage sur ElementArrayFinder :

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

Veuillez passer à [email protected] . Il semble être résolu là.

@demisx je l'ai patché ici et ça marche pour moi

@rafalf Merci. Si vous parlez de "prendre l' index.js de selenium-3.7.0 et d'ajouter ECONNREFUSED", j'ai essayé cela, mais j'obtenais toujours cette erreur de temps en temps. S'il vous plaît laissez-moi savoir si j'ai mal compris votre commentaire.

L'erreur EPIPE se produit encore assez souvent avec le dernier rapporteur 5.4.1, chromedriver_2.43 et async/wait sur MacOS Mojave. Nous ne pouvons plus exécuter les spécifications E2E sur CI. Effectuez plusieurs exécutions manuelles jusqu'à ce qu'elles soient toutes réussies. Très instable.

@demisx
cela se produit principalement pour moi pour each , filter et d'autres fonctions qui sont utilisées avec des tableaux

comment je l'ai retravaillé

        // 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 Ouais, c'est la première chose dont nous nous sommes débarrassés. Bien que cela ait réduit la fréquence des erreurs EPIPE, elles n'ont pas complètement disparu. Cela s'aggrave lors de l'exécution d'un rapporteur avec plusieurs capacités. Donc, jusqu'à présent, le patch @kylecordes semble faire le travail. Merci @kylecordes ! Espérons que ce correctif arrivera bientôt à master .

Hors sujet, vous n'avez pas besoin await dans let l = await $$("q-short-list-component.ng-valid mat-label") . Le $$ renvoie ElementArrayFinder , pas une promesse. 😉

@demisx non tu te trompes, c'est peut-être pour ça que tu as encore des erreurs EPIPE :dancer:
Oui - il renvoie ElementArrayFinder sans attendre mais vous ne pourrez pas le parcourir
et cette partie ne fonctionnerait pas

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

si je fais await , j'obtiens une liste d'éléments ;) que je peux parcourir

@rafalf Désolé, mon mauvais. J'ai raté la partie d'itération sous le await . Vous avez tout à fait raison.

Je peux me tromper, mais il semble que de telles erreurs se produisent par intermittence pour moi partout où il y a une utilisation de ElementArrayFinder de la manière suivante :
await $$('some-selector').click()

@yyankowski Oui, c'était aussi mon expérience. J'ai vu cette erreur se produire avec $$ plus qu'autre chose. Surtout, lorsque vous essayez d'appeler une méthode sur le ElementArrayFinder retourné par $$ .