Я тоже довольно часто с этим сталкивался. Похоже, это происходит чаще, может быть, исключительно, когда Chrome находится в фоновом режиме. Может просто совпадение

Да, я тоже получил эту уродливую ошибку!

Приносим извинения за поздний ответ здесь; Я не стал это воспроизводить. Может ли кто-нибудь из вас предоставить небольшой пример репозитория (вы можете использовать https://github.com/NickTomlin/protractor-mcve в качестве стартера) приложения angular 2, которое воспроизводит это?

Удаление потока управления — это шаг в правильном направлении, но он может выявить некоторые проблемы (например, эту), которые нам необходимо учитывать. Спасибо!

@NickTomlin @wcainboundary Я только что обновил свой nodejs до последней стабильной версии, и теперь он работает нормально.

Не сработало:

$node -v
v6.10.1

Работает отлично:

$node -v
v7.10.0

Я вижу ошибку в узле v8.0.0

Я также вижу эту ошибку _без_ транспортира (прямо [email protected] и я думаю 3.3 до этого). Никогда не происходит в OS X, но довольно часто в наших агентах сборки (Linux).

Я не видел этой проблемы, поданной против Selenium, но, вероятно, это должно быть.

Я видел эту ошибку в OSX.

Для меня проблема была связана со временем. Мой тест пытался взаимодействовать с недоступным элементом. Хотя задачи angular были завершены, некоторый рендеринг на странице не был завершен, что привело к этой проблеме. Это было легче воспроизвести в нашей размещенной сетке, поскольку соединения были медленнее.

Я видел это, когда для параметра waitForAngularEnabled установлено значение true и false.

До обновления мы получали ошибки тайм-аута в некоторых из тех же тестов. Интересно, Webdriver 3.x просто говорит то же самое по-другому...

+1 к этому, столкнулся с той же проблемой при локальном запуске моих спецификаций в OS X 10.12.5.

Что бы это ни стоило, я с меньшей вероятностью увидел ошибку EPIPE на:

• Узел 7.10.1
• ОС X 10.12.5
• Протактор 5.1.2
• Хром 59.0.3071.115

И когда я говорю _маловероятно_, я имею в виду, что когда я запускал свой пакет 7 раз с моей вышеуказанной конфигурацией, 4 запуска были успешными, если я сразу же сфокусировал свой браузер Chrome и не перемещал мышь от значка дока Chrome (вероятно, не относится).

В нашем проекте появлялись ошибки EPIPE , потому что тесты (в TypeScript) неправильно использовали await s. И поэтому необработанные отклонения промисов происходили случайным образом и приводили к этим ошибкам. После того, как я исправил неправильное использование, у нас больше нет этих ошибок на Node 8.

Попробуйте тщательно проверить свои тесты на предмет неправильного использования await (либо отсутствующего, либо избыточного) или просто неправильного связывания промисов (например, когда вы забыли вернуть промис из вспомогательных методов). В нашем случае типичной ошибкой было использование:

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

вместо:

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

Может быть, это поможет кому-то, кто также имеет эту проблему.

Исправлена ​​ли эта проблема? Я все еще вижу это с версией узла 7.7.3 и версией транспортира 5.1.1.

@ sri1987 см. мой комментарий выше. Скорее всего, проблема в вашем коде, а не в Protractor.

@ sri1987 Если это не воспроизводится последовательно, это определенно связано с отсутствием / дополнительным await где-то.

В последнее время очень часто возникает эта ошибка с SELENIUM_PROMISE_ MANAGER: false
При запуске нескольких тестов

Проблема здесь и в # 4507, похоже, заключается в параллельных командах веб-драйвера. @wvanderdeijl предложил решение для частного случая ElementArrayFinder::map() в #4508. Пока это не будет разрешено должным образом, следующая оболочка для browser.driver.schedule() , которая создает очередь для предотвращения выполнения любых параллельных команд веб-драйвера, может быть обходным путем.

Может ли кто-нибудь, кто испытывает ошибки EPIPE, регулярно проверять это? Это может в некоторой степени замедлить выполнение теста.

Например, следующий код можно вызвать в хуке Protractor onPrepare() .

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

или с некоторой дополнительной регистрацией:

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
Я думаю, что вы там на месте. Я сузил, что большинство моих ошибок исходят от функций, которые возвращают вызов Promise.all, поэтому я совершенно уверен, что это должно иметь какое-то отношение к параллелизму.

@renehamburger спасибо. После добавления этого в раздел onPrepare моего 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;
};

Ошибка «Ошибка: EPIPE записать EPIPE» исчезла.

@ Xaz16 : сработало для нас как обходной путь, спасибо!

Но ошибки «EPIPE write EPIPE», похоже, являются ошибкой в ​​Selenium: https://github.com/SeleniumHQ/selenium/issues/5345 , которая будет решена в 4.0.0.

Поэтому нам нужно подождать, пока Protractor использует версию 4.0.0, и тогда мы сможем удалить этот обходной путь.

У нас есть ссылка на дорожную карту Protractor ? Или его вообще нет

@renehamburger , не могли бы вы помочь? Я пытаюсь переписать ваш обходной путь в случае, когда SELENIUM_PROMISE_MANAGER: false . В настоящее время, если я просто скопирую/вставлю ваше решение, возникнет много странных проблем, которые, как мне кажется, можно решить с помощью async/await .

@CrispusDH Мне пришлось изменить фрагмент кода на

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

Так что в основном удалите .driver

Использование Async/await кажется большим беспорядком, чем controlFlow.

Ошибка по-прежнему наблюдается в Mac OS Sierra даже после попытки вышеуказанного решения.

Есть ли другое решение, которое можно попробовать.

Спасибо

В нашем случае это неправильное использование async/await в некоторых утверждениях.

было это:

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

вместо:

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

Привет @danigar Функция isDisplayed() возвращает обещание, поэтому важно использовать ожидание, если вы хотите решить эту проблему. Итак, ваша вторая строка кода во втором примере выглядит нормально.
Как насчет await в вашей первой строке, это зависит от того, что return getModalInfo() . На данный момент это неясно, и я не вижу связи между 1-й и 2-й линиями.

@marcincharezinski jasmine разрешит Promise в except() самостоятельно без await .

Ага. Извините за задержку @marcincharezinski. Метод getModalInfo() в первой строке вернул ElementFinder (не завернутый в промис), и, как вы видите в первом примере, мы получили для него awaiting .
У нас были некоторые подобные проблемы, и как только мы их исправили, ошибка EPIPE исчезла 😊.

@CrispusDH - Раньше я думал так же, пока не начал сталкиваться с проблемами, связанными с неудачными тестами по причинам, которые я не мог понять. Я вернулся и добавил await в свои операторы except() , и это прояснило их.

@Mokkapps По крайней мере, в TypeScript ваш код выдает ошибку:
Тип '(команда: Command, описание: строка) => Promise void' не может быть назначен типу ' T (команда: Command, описание: строка) => Promise T'.
Тип «Promise void» не может быть назначен типу «Promise T».
Свойство «отмена» отсутствует в типе «Обещание недействительно».

@кахан002

Мы, наконец, решили это, используя этот код

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

который вызывается в protractor.conf.ts

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

Спасибо @Mokkapps за то, что поделились этим. Пара замечаний на случай, если кто-то захочет адаптировать его для typeScript и такой среды, как моя. os.platform() не было известно, поэтому я использовал process.platform . Мне пришлось import { Command } from "selenium-webdriver"; Мне пришлось закомментировать concurrencyCounter, так как он никогда не читался. А так как у меня есть предупреждение typeScript о неявном any, мне нужно было сделать их явными в .then((result : any) => { и .catch((error: any) => { . Я не жалуюсь на код, и я рад, что вы им поделились (кажется, он решил проблему, хотя немного сложно сказать, так как он был прерывистым). Я надеюсь, что этот комментарий будет кому-то полезен. Большое спасибо, что ответили мне и другим.
Но, возможно, мои изменения нарушили ваше исправление, потому что я только что получил UnhandledPromiseRejectionWarning: отклонение необработанного обещания (идентификатор отклонения: 4): ошибка: EPIPE write EPIPE
(узел: 8514) [DEP0018] Предупреждение об устаревании: отказы от необработанных обещаний устарели. В будущем отказы от обещаний, которые не будут обработаны, завершат процесс Node.js с ненулевым кодом выхода.
после всего. Я вернусь и посмотрю, где я неправильно использую await .

Есть ли прогресс для пользователей OSX?

Я думаю, что это может быть вызвано той же ситуацией, что и некоторые другие подобные ошибки, исправлением для которых является использование проверки активности HTTP при обмене данными между кодом Selenium Node и браузером. Для этого есть исправление в основной ветке Selenium в прошлом году, но оно не опубликовано ни в одной версии этого кода.

Вот обходной путь, который мы используем здесь, заимствованный и отредактированный из того, что написал другой комментатор в другом выпуске. Настройте package.script NPM для его запуска:

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

Код патчера:

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

С этим патчем Protractor надежен на 99%+ как для Windows, так и для OSX, используя SELENIUM_PROMISE_MANAGER: false . Ваш пробег может варьироваться в зависимости от того, вызвана ли ваша ошибка EPIPE той же основной ситуацией, что и наша.

Я считаю, что ожидания с цепочками (или над массивами) кажутся наиболее уязвимыми. Так, например, я только что увидел ошибку с let testFormatID: string =await element.all(by.className('ng-star-inserted')).all(by.tagName('td')).get(1). получитьтекст(); Возможно, что ошибка моя и то, что я написал, не должно работать.

# 4792 , похоже, исправила мои проблемы с Mac OS X. Спасибо за подсказку, Игорь Дорохов.

@kahan002 Добро пожаловать!

любое ETA для 4.0.0-alpha.1 включено в транспортир?

4792 не решил проблему для меня. Все еще получаю ошибку Failed: EPIPE write EPIPE 1 из 5 при фильтрации в ElementArrayFinder:

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

Пожалуйста, обновитесь до [email protected] . Там вроде решено.

@demisx Я исправил это здесь, и у меня это работает

@rafalf Спасибо. Если вы говорите о том, чтобы «взять index.js из selenium-3.7.0 и добавить ECONNREFUSED», то я пробовал это, но иногда все еще получал эту ошибку. Пожалуйста, дайте мне знать, если я неправильно понял ваш комментарий.

Ошибка EPIPE все еще довольно часто возникает с последним транспортиром 5.4.1, chromedriver_2.43 и async/await в MacOS Mojave. Мы больше не можем запускать спецификации E2E в CI. Выполните несколько ручных прогонов, пока все они не пройдут. Очень нестабильный.

@demisx
это в основном происходит для меня для each , filter и других функций, которые используются с массивами

как я его переделал

        // 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 Да, это было первое, от чего мы избавились. Хотя частота ошибок EPIPE уменьшилась, полностью они не исчезли. Ситуация ухудшается при запуске транспортира с несколькими возможностями. Итак, патч @kylecordes , похоже, делает свою работу. Спасибо @kylecordes! Надеемся, что это исправление скоро превратится в master .

Не по теме, вам не нужно await в let l = await $$("q-short-list-component.ng-valid mat-label") . $$ возвращает ElementArrayFinder , а не обещание. 😉

@demisx нет, вы ошибаетесь, может быть, поэтому вы все еще получаете ошибки EPIPE :dancer:
Да - он возвращает ElementArrayFinder без ожидания, но вы не сможете перебрать его
и эта часть не будет работать

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

если я делаю await , я получаю список элементов;), которые я могу пройти

@rafalf Извини, мой плохой. Я пропустил часть итерации ниже await . Вы абсолютно правы.

Я могу ошибаться, но похоже, что такие ошибки периодически возникают у меня везде, где используется ElementArrayFinder следующим образом:
await $$('some-selector').click()

@yyankowski Да, это был и мой опыт. Я видел, что эта ошибка происходит с $$ больше, чем с чем-либо еще. Особенно при попытке вызвать метод для ElementArrayFinder , возвращаемого $$ .