لقد كنت أصطدم بهذا كثيرًا أيضًا. يبدو أنه يحدث في كثير من الأحيان ، ربما على وجه الحصر ، عندما يكون Chrome في الخلفية. قد يكون مجرد صدفة

نعم لدي هذا الخطأ القبيح أيضًا!

نعتذر عن الرد المتأخر هنا ؛ لم أتمكن من إعادة إنتاج هذا. هل يمكن لأحدكم أن يقدم نموذجًا صغيرًا من الريبو (يمكنك استخدام https://github.com/NickTomlin/protractor-mcve كبداية) لتطبيق angular 2 الذي يعيد إنتاج هذا؟

تعد إزالة تدفق التحكم خطوة في الاتجاه الصحيح ولكنها قد تكشف عن بعض المشكلات (مثل هذه المشكلة) التي سنحتاج إلى حسابها. شكرا!

NickTomlinwcainboundary لقد قمت للتو بترقية nodejs الخاص بي إلى أحدث إصدار مستقر وهو يعمل بشكل جيد الآن.

لم يعمل:

$node -v
v6.10.1

يعمل بشكل جيد:

$node -v
v7.10.0

أرى الخطأ في العقدة v8.0.0

أرى أيضًا هذا الخطأ _ بدون منقلة (مباشرة [email protected] وأعتقد 3.3 قبله). لا يحدث هذا مطلقًا على OS X ، ولكنه يحدث كثيرًا على وكلاء الإنشاء (Linux).

لم أر هذه القضية مرفوعة ضد السيلينيوم ، لكن من المحتمل أن تكون كذلك.

لقد رأيت هذا الخطأ في OSX.

بالنسبة لي كانت القضية متعلقة بالتوقيت. كان اختباري يحاول التفاعل مع عنصر لم يكن متاحًا. على الرغم من اكتمال المهام الزاوية ، إلا أن بعض عمليات العرض على الصفحة لم تكتمل مما أدى إلى حدوث هذه المشكلة. كان من الأسهل إعادة الإنتاج على شبكتنا المستضافة نظرًا لأن الاتصالات كانت أبطأ.

لقد رأيت هذا مع تعيين waitForAngularEnabled إلى "صواب وخطأ".

قبل الترقية ، اعتدنا الحصول على أخطاء انتهاء المهلة في بعض الاختبارات نفسها. أتساءل عما إذا كان Webdriver 3.x يقول الشيء نفسه بطريقة مختلفة ...

+1 على هذا الأمر ، حيث واجهت نفس المشكلة عند تشغيل المواصفات الخاصة بي محليًا على OS X 10.12.5

لما يستحق ، كنت أقل احتمالا لرؤية خطأ EPIPE على:

• العقدة 7.10.1
• OSX 10.12.5
• بروتاكتور 5.1.2
• كروم 59.0.3071.115

وعندما أقول _ على الأرجح _ ، أعني أنه عندما قمت بتشغيل مجموعتي 7 مرات مع التهيئة أعلاه ، كانت 4 من عمليات التشغيل ناجحة إذا ركزت على الفور على متصفح Chrome ولم أحرك الماوس من أيقونة Chrome dock (ربما غير مرتبط).

في مشروعنا ، ظهرت أخطاء EPIPE ، لأن الاختبارات (في TypeScript) كانت تستخدم await s بشكل غير صحيح. وبالتالي ، فإن رفض الوعد الذي لم يتم التعامل معه كان يحدث بشكل عشوائي ويؤدي إلى هذه الأخطاء. بمجرد إصلاح الاستخدامات غير الصحيحة ، لم تعد لدينا هذه الأخطاء على Node 8.

حاول التحقق من الاختبارات بعناية بحثًا عن استخدامات غير صحيحة لـ await (إما مفقودة أو زائدة عن الحاجة) أو مجرد تسلسل وعد غير صحيح (على سبيل المثال عندما نسيت إرجاع Promise من الطرق المساعدة). في حالتنا ، كان الخطأ النموذجي يستخدم:

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

بدلا من:

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

ربما سيساعد شخصًا ما لديه هذه المشكلة أيضًا.

هل تم حل هذه المشكلة؟ ما زلت أراه مع إصدار العقدة 7.7.3 وإصدار المنقلة 5.1.1

@ sri1987 انظر تعليقي أعلاه. من المرجح أن تكون مشكلة في التعليمات البرمجية الخاصة بك ، وليس في منقلة.

@ sri1987 إذا لم يكن قابلاً للتكرار باستمرار ، فمن المؤكد أنه مرتبط بفقدان / إضافي await في مكان ما.

حصلت على هذه الأخطاء كثيرًا مؤخرًا مع SELENIUM_PROMISE_ MANAGER: خطأ
عند إجراء اختبارات متعددة

يبدو أن المشكلة هنا وفي # 4507 هي أوامر webdriver متزامنة. اقترح wvanderdeijl حلاً للحالة الخاصة ElementArrayFinder::map() في # 4508. حتى يتم حل هذا الأمر بشكل صحيح ، قد يكون الغلاف التالي لـ browser.driver.schedule() ، والذي ينشئ قائمة انتظار لمنع تنفيذ أي أوامر متزامنة من محرك الويب ، حلاً بديلاً.

هل يمكن لشخص يعاني من أخطاء EPIPE اختبار ذلك بانتظام؟ قد يبطئ تنفيذ الاختبار إلى حد ما.

يمكن استدعاء الكود التالي في خطاف منقلة 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 شكرا لك. بعد إضافة هذا إلى قسم 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 write EPIPE".

@ Xaz16 : عملت بالنسبة لنا كحل بديل ، شكرا!

ولكن يبدو أن أخطاء "EPIPE write EPIPE" هي خطأ في السيلينيوم: 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 / wait يمثل فوضى أكبر من controlFlow.

لا يزال يتم ملاحظة الخطأ على نظام التشغيل Mac OS Sierra حتى بعد تجربة الحل أعلاه.

هل هناك أي حل آخر يمكن تجربته.

شكرا

في حالتنا يبدو أن هناك استخدام خاطئ للتزامن / انتظار في بعض التأكيدات.

كان هذا:

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

بدلا من:

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

HiDanigar Function isDisplayed() وعد بالإرجاع لذا من الضروري استخدام الانتظار إذا كنت تريد حلها. لذا يبدو السطر الثاني من التعليمات البرمجية في المثال الثاني جيدًا.
ماذا عن await في السطر الأول ، فهذا يعتمد على العائد getModalInfo() . من غير الواضح في هذه المرحلة ولا يمكنني رؤية الاتصال بين الخطين الأول والثاني.

marcincharezinski jasmine سيعمل على حل Promise في except() بنفسك بدون await .

نعم. آسف على التأخير marcincharezinski. عادت طريقة getModalInfo() للسطر الأول إلى ElementFinder (غير ملفوف في وعد) ، وكما ترى في المثال الأول كنا awaiting لذلك.
كانت لدينا بعض المشكلات مثل هذه وبمجرد إصلاحها ، اختفى خطأ EPIPE.

CrispusDH - كنت أفكر في نفس الشيء حتى ظللت أتلقى مشكلات حول فشل الاختبارات لأسباب لم أستطع فهمها. عدت وأضفت await داخل كشوف حساباتي except() وهذا ما أزالها.

Mokkapps على الأقل في TypeScript يعطي الكود الخطأ:
نوع '(الأمر: الأمر: الوصف: سلسلة) => Promise void 'غير قابل للتخصيص لكتابة' T (الأمر: الأمر ، الوصف: سلسلة) => Promise T '.
اكتب "Promise void" غير قابل للتخصيص لكتابة "Promise T".
الخاصية "إلغاء" مفقودة في نوع "الوعد باطل".

@ kahan002

لقد حللناها أخيرًا باستخدام هذا الرمز

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

وهو ما يسمى في منقلة .conf.ts

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

شكرا Mokkapps لتقاسم ذلك. بضع ملاحظات في حالة رغبة شخص ما في تكييفها مع typeScript وبيئة مثل بيئتي. لم يكن os.platform() معروفًا ، لذا استخدمت process.platform . اضطررت إلى import { Command } from "selenium-webdriver"; كان علي أن أعلق على concurrencyCounter لأنه لم يتم قراءته مطلقًا. ونظرًا لوجود تحذير من نوع typeScript بشأن أي تحذير ضمني ، فقد احتجت إلى جعلها صريحة في .then((result : any) => { و .catch((error: any) => { . أنا لا أشكو من الكود ، ويسعدني أنك شاركته (يبدو أنه يحل المشكلة ، على الرغم من صعوبة معرفة ذلك لأنه كان متقطعًا). آمل أن يكون هذا التعليق مفيدًا لشخص ما. شكرًا جزيلاً على العودة إليّ وإلى الآخرين.
لكن ربما أدت التغييرات التي أجريتها إلى تعطل الإصلاح الذي أجريته ، لأنني تلقيت للتو UnhandledPromiseRejection تحذير: رفض الوعد الذي لم تتم معالجته (معرّف الرفض: 4): خطأ: EPIPE اكتب EPIPE
(العقدة: 8514) [DEP0018] تحذير الإيقاف: تم إهمال رفض الوعود غير المعالجة. في المستقبل ، ستؤدي حالات رفض الوعد التي لم تتم معالجتها إلى إنهاء عملية Node.js برمز إنهاء غير صفري.
بعد كل ذلك. سأعود وأرى أين يجب أن أسيء استخدام await .

أي تقدم لمستخدمي OSX؟

أعتقد أن هذا قد يكون ناتجًا عن نفس الموقف مثل بعض الأخطاء الأخرى المماثلة ، والتي يتمثل الإصلاح لها في استخدام HTTP المستمر في الاتصال بين كود Selenium Node والمستعرض. يوجد إصلاح لهذا في خط السيلينيوم الرئيسي ، العام الماضي - لكن لم يتم نشره في أي إصدار من هذا الرمز.

هذا هو الحل الذي نستخدمه هنا ، والذي تم استعاره وتحريره من شيء كتبه معلق آخر في عدد آخر. قم بإعداد حزمة NPM.script لتشغيلها:

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

مع هذا التصحيح ، تعتبر المنقلة قوية بنسبة 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. شكرًا للنصيحة ، IgorDorokhov.

@ kahan002 اهلا وسهلا بكم!

أي ETA لـ 4.0.0-alpha.1 مدرج في المنقلة؟

4792 لم يصلح المشكلة بالنسبة لي. لا يزال يتم تلقي Failed: EPIPE write EPIPE error 1 من أصل 5 أثناء إجراء التصفية على ElementArrayFinder:

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

الرجاء الترقية إلى [email protected] . يبدو أنه تم حلها هناك.

demisx لقد قمت بتصحيحه هنا وهو يعمل بالنسبة لي

rafalf شكرا لك. إذا كنت تتحدث عن "أخذ index.js من السيلينيوم 3.7.0 وإضافة ECONNREFUSED" فقد حاولت ذلك ، لكنني ما زلت أتلقى هذا الخطأ من حين لآخر. يرجى إعلامي إذا أسأت فهم تعليقك.

لا يزال خطأ EPIPE يحدث كثيرًا مع أحدث منقلة 5.4.1 و chromedriver_2.43 وغير متزامن / ينتظر على MacOS Mojave. لا يمكننا تشغيل مواصفات E2E على CI بعد الآن. خذ عدة دورات يدوية حتى تمر جميعها. غير مستقر للغاية.

تضمين التغريدة
يحدث هذا بشكل أساسي بالنسبة لي مقابل each ، filter والوظائف الأخرى التي تستخدم مصفوفات iwth

كيف أعدت صياغته

        // 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: راقصة:
نعم - تقوم بإرجاع ElementArrayFinder بدون انتظار ولكن لن تتمكن من تكرار ذلك
وهذا الجزء لن يعمل

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

إذا قمت بعمل await ، فسأحصل على قائمة بالعناصر ؛) التي يمكنني المرور بها

rafalf آسف يا سيئة. فاتني جزء التكرار أسفل await . أنت محق تمامًا.

قد أكون مخطئًا ولكن يبدو أن مثل هذه الأخطاء تحدث بشكل متقطع بالنسبة لي أينما كان هناك استخدام لـ ElementArrayFinder بالطريقة التالية:
await $$('some-selector').click()

yyankowski نعم ، لقد كانت تجربتي أيضًا. لقد رأيت هذا الخطأ يحدث مع $$ أكثر من أي شيء آخر. خاصة ، عند محاولة استدعاء طريقة على ElementArrayFinder يتم إرجاعها بواسطة $$ .