Eu também tenho esbarrado nisso com bastante frequência. Parece que isso acontece com mais frequência, talvez exclusivamente, quando o Chrome está em segundo plano. Pode ser apenas uma coincidência

Sim, eu também recebi esse erro feio!

Desculpas pela resposta tardia aqui; Não cheguei a reproduzir isso. Um de vocês poderia fornecer um pequeno repositório de exemplo (você pode usar https://github.com/NickTomlin/protractor-mcve como inicializador) de um aplicativo angular 2 que reproduz isso?

A remoção do fluxo de controle é um passo na direção certa, mas pode revelar alguns problemas (como este) que precisaremos considerar. Obrigado!

@NickTomlin @wcainboundary Acabei de atualizar meus nodejs para a versão estável mais recente e funciona bem agora.

Não funcionou:

$node -v
v6.10.1

Funciona bem:

$node -v
v7.10.0

Estou vendo o erro no nó v8.0.0

Também estou vendo este erro _without_ transferidor (straight [email protected] e acredito que 3.3 antes dele). Nunca acontece no OS X, mas com bastante frequência em nossos agentes de compilação (Linux).

Eu não vi esse problema arquivado contra o Selenium, mas provavelmente deveria ser.

Eu vi esse erro no OSX.

Para mim, o problema estava relacionado ao tempo. Meu teste estava tentando interagir com um elemento que não estava disponível. Embora as tarefas angulares tenham sido concluídas, algumas renderizações na página não foram concluídas, o que levou a esse problema. Foi mais fácil reproduzir em nossa grade hospedada, pois as conexões eram mais lentas.

Eu vi isso com waitForAngularEnabled definido como true e false.

Antes da atualização, costumávamos obter erros de tempo limite em alguns dos mesmos testes. Gostaria de saber se o Webdriver 3.x está apenas dizendo a mesma coisa de uma maneira diferente ...

+1 nisso, enfrentando o mesmo problema ao executar minhas especificações localmente no OS X 10.12.5

Pelo que vale a pena, era menos provável que eu visse o erro EPIPE em:

• Nó 7.10.1
• OSX 10.12.5
• Protador 5.1.2
• Chrome 59.0.3071.115

E, quando digo _menos provável_, quero dizer que quando executei minha suíte 7 vezes com minha configuração acima, 4 das execuções foram bem-sucedidas se eu imediatamente focasse meu navegador Chrome e não movesse meu mouse do ícone do dock do Chrome (provavelmente não relacionado).

Em nosso projeto estavam aparecendo erros EPIPE , porque os testes (em TypeScript) estavam usando incorretamente await s. E, portanto, rejeições de promessas não tratadas estavam acontecendo aleatoriamente e levando a esses erros. Depois de corrigir usos incorretos, não temos mais esses erros no Node 8.

Tente verificar seus testes cuidadosamente para usos incorretos de await (ausente ou redundante) ou apenas encadeamento incorreto de Promise (por exemplo, quando você esqueceu de retornar Promise de métodos auxiliares). No nosso caso, o erro típico estava usando:

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

em vez de:

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

Talvez ajude alguém que também tenha esse problema.

Este problema é corrigido? Ainda o vejo com a versão 7.7.3 do nó e a versão 5.1.1 do transferidor

@ sri1987 veja meu comentário acima. É mais provável que seja um problema no seu código, não no transferidor.

@ sri1987 Se não for reproduzível de forma consistente, definitivamente está relacionado à falta/extra await em algum lugar.

Recebi esses erros com muita frequência ultimamente com SELENIUM_PROMISE_ MANAGER:false
Ao executar vários testes

O problema aqui e em #4507 parece ser comandos simultâneos do webdriver. @wvanderdeijl sugeriu uma solução para o caso particular de ElementArrayFinder::map() em #4508. Até que isso seja resolvido corretamente, o seguinte wrapper para browser.driver.schedule() , que cria uma fila para impedir a execução de comandos simultâneos do webdriver, pode ser uma solução alternativa.

Alguém que está enfrentando erros de EPIPE pode testar isso regularmente? Isso pode retardar a execução do teste até certo ponto.

O código a seguir pode ser chamado no gancho onPrepare() do Protractor, por exemplo.

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 com algum 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
Acho que você está certinho aí. Eu reduzi a maioria dos meus erros eram provenientes de funções que retornam uma chamada Promise.all, então tenho certeza de que deve ter algo a ver com simultaneidade

@renehamburger obrigado. Depois de adicionar este à seção onPrepare do meu transferidor.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;
};

Erro 'Falha: EPIPE write EPIPE' desapareceu.

@ Xaz16 : Funcionou para nós como solução alternativa, obrigado!

Mas os erros "EPIPE write EPIPE" parecem ser um bug no Selenium: https://github.com/SeleniumHQ/selenium/issues/5345 que será resolvido na 4.0.0.

Portanto, temos que esperar até que o Protractor use a versão 4.0.0 e possamos remover essa solução alternativa.

Temos algum link para o roteiro Protractor ? Ou não existe em tudo

@renehamburger , você poderia ajudar? Eu tento reescrever sua solução alternativa no caso de SELENIUM_PROMISE_MANAGER: false . Atualmente, se eu apenas copiar/colar sua solução, há muitos problemas estranhos que acho que podem ser resolvidos usando async/await .

@CrispusDH eu tive que mudar o trecho de código para

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

Então, basicamente, remova o .driver

Usar Async/await parece ser uma bagunça maior que o controlFlow.

O erro ainda é observado no Mac OS Sierra mesmo depois de tentar a solução acima.

Existe alguma outra solução que pode tentar.

Obrigado

No nosso caso parece ser um uso errado de async/await em algumas assertivas.

teve isso:

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

em vez de:

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

Oi @danigar Função isDisplayed() retorna promessa, então é essencial usar await se você quiser resolvê-lo. Portanto, sua segunda linha de código no segundo exemplo parece bem.
E quanto await na sua primeira linha, depende de qual retorno getModalInfo() . Não está claro neste momento e não consigo ver a conexão entre a 1ª e a 2ª linhas.

@marcincharezinski jasmine resolverá Promise em except() sozinho sem await .

Sim. Desculpe a demora @marcincharezinski. O método getModalInfo() da primeira linha retornou um ElementFinder (não envolto em uma promessa), e como você vê no primeiro exemplo, estávamos awaiting para isso.
Tivemos alguns problemas como esses e, assim que os corrigimos, o erro do EPIPE desapareceu 😊.

@CrispusDH - Eu costumava pensar a mesma coisa até continuar tendo problemas com testes que falhavam por motivos que não conseguia entender. Voltei e adicionei await dentro das minhas declarações except() e isso as esclareceu.

@Mokkapps Pelo menos no TypeScript seu código dá o erro:
Modelo '(comando: Comando, descrição: string) => Promise void' não pode ser atribuído ao tipo ' T (command: Command, description: string) => Promise T'.
O tipo 'Promise void' não pode ser atribuído ao tipo 'Promise T'.
A propriedade 'cancel' está ausente no tipo 'Promise void'.

@kahan002

Finalmente resolvemos isso 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 é chamado em transferidor.conf.ts

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

Obrigado @Mokkapps por compartilhar isso. Algumas notas caso alguém queira adaptá-lo para typeScript e um ambiente como o meu. os.platform() não era conhecido, então usei process.platform . Eu tive que import { Command } from "selenium-webdriver"; eu tive que comentar o concurrencyCounter desde que nunca foi lido. E como eu tenho um aviso de typeScript em qualquer implícito, eu precisava torná-los explícitos em .then((result : any) => { e .catch((error: any) => { . Não estou reclamando do código e estou feliz que você o compartilhou (parece corrigir o problema, embora seja um pouco difícil dizer, pois era intermitente). Espero que este comentário seja útil para alguém. Muito obrigado por voltar para mim e para os outros.
Mas talvez minhas alterações tenham quebrado sua correção, porque acabei de receber UnhandledPromiseRejectionWarning: Rejeição de promessa não tratada (ID de rejeição: 4): Erro: EPIPE write EPIPE
(node:8514) [DEP0018] DeprecationWarning: As rejeições de promessa não tratadas estão obsoletas. No futuro, as rejeições de promessas que não forem tratadas encerrarão o processo Node.js com um código de saída diferente de zero.
depois de tudo. Vou voltar e ver onde devo estar usando mal await .

Algum progresso para usuários do OSX?

Acho que isso pode ser desencadeado pela mesma situação que alguns outros erros semelhantes, cuja correção é usar o HTTP keep-alive na comunicação entre o código do Selenium Node e o navegador. Existe uma correção para isso na linha principal do Selenium, no ano passado - mas não foi publicada em nenhuma versão desse código.

Aqui está a solução que usamos aqui, emprestada e editada de algo que outro comentarista escreveu em outra edição. Configure um package.script do NPM para executá-lo:

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

O código do patcher é:

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

Com este patch, o Protractor é 99%+ robusto para nós tanto no Windows quanto no OSX, usando SELENIUM_PROMISE_MANAGER: false . Sua milhagem pode variar, dependendo se o erro do seu EPIPE é causado pela mesma situação subjacente que a nossa.

Acho que espera com cadeias (ou sobre matrizes) parece mais vulnerável. Então, por exemplo, acabei de ver o erro com let testFormatID: string =await element.all(by.className('ng-star-inserted')).all(by.tagName('td')).get(1). getText(); É possível que o erro seja meu e que o que escrevi não funcione.

#4792 parece ter corrigido meus problemas no Mac OS X. Obrigado pela dica, IgorDorokhov.

@kahan002 de nada!

qualquer ETA para 4.0.0-alpha.1 incluído no transferidor?

4792 não resolveu o problema para mim. Ainda recebendo Failed: EPIPE write EPIPE erro 1 de 5 ao fazer a filtragem no ElementArrayFinder:

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

Por favor, atualize para [email protected] . Parece que está resolvido lá.

@demisx eu corrigi aqui e funciona para mim

@rafalf Obrigado. Se você está falando sobre "pegar o index.js do selenium-3.7.0 e adicionar ECONNREFUSED", eu tentei isso, mas ainda estava recebendo esse erro ocasionalmente. Por favor, deixe-me saber se eu entendi mal o seu comentário.

O erro EPIPE ainda acontece com bastante frequência com o transferidor mais recente 5.4.1, chromedriver_2.43 e async/await no MacOS Mojave. Não podemos mais executar especificações E2E no CI. Faça várias execuções manuais até que todas passem. Muito instável.

@demisx
isso está acontecendo principalmente para mim para each , filter e outras funções que são usadas com matrizes

como eu reformulei

        // 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 Sim, essa foi a primeira coisa da qual nos livramos. Embora tenha reduzido a frequência de erros do EPIPE, eles não desapareceram completamente. Está piorando ao executar o transferidor com vários recursos. Então, agora o patch @kylecordes parece estar fazendo o trabalho. Obrigado @kylecordes! Espero que essa correção chegue a master breve.

Fora do tópico, você não precisa await em let l = await $$("q-short-list-component.ng-valid mat-label") . O $$ retorna ElementArrayFinder , não uma promessa. 😉

@demisx não, você está errado, talvez seja por isso que você ainda recebe erros EPIPE :dancer:
Sim - ele retorna ElementArrayFinder sem aguardar, mas você não poderá iterar sobre ele
e essa parte não funcionaria

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

se eu fizer await , recebo uma lista de elementos ;) que posso passar

@rafalf Desculpe, foi mal. Eu perdi a parte da iteração abaixo do await . Você está absolutamente correto.

Posso estar enganado, mas parece que esses erros acontecem intermitentemente para mim onde quer que haja um uso de ElementArrayFinder da seguinte maneira:
await $$('some-selector').click()

@yyankowski Sim, também foi minha experiência. Eu vi esse erro acontecendo com $$ mais do que qualquer outra coisa. Especialmente, ao tentar chamar um método no ElementArrayFinder retornado por $$ .