Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

investigate flaky test-http2-respond-file-error-pipe-offset #35881

Closed
Trott opened this issue Oct 30, 2020 · 12 comments · Fixed by #36305
Closed

investigate flaky test-http2-respond-file-error-pipe-offset #35881

Trott opened this issue Oct 30, 2020 · 12 comments · Fixed by #36305
Labels
flaky-test Issues and PRs related to the tests with unstable failures on the CI. http2 Issues or PRs related to the http2 subsystem.

Comments

@Trott
Copy link
Member

Trott commented Oct 30, 2020

  • Test: test-http2-respond-file-error-pipe-offset
  • Platform: several (alpine-last-latest-x64, ubuntu1804_sharedlibs_debug, probably others)
  • Console Output:
not ok 1252 parallel/test-http2-respond-file-error-pipe-offset
  ---
  duration_ms: 0.298
  severity: fail
  exitcode: 1
  stack: |-
    node:assert:885
        throw newErr;
        ^
    
    AssertionError [ERR_ASSERTION]: ifError got unwanted exception: EPIPE: broken pipe, write
        at /home/iojs/build/workspace/node-test-commit-linux/nodes/alpine-last-latest-x64/test/common/index.js:340:12
        at /home/iojs/build/workspace/node-test-commit-linux/nodes/alpine-last-latest-x64/test/common/index.js:377:15
        at close (node:fs:1417:11)
        at FSReqCallback.oncomplete (node:fs:171:23)
     {
      generatedMessage: false,
      code: 'ERR_ASSERTION',
      actual: [Error: EPIPE: broken pipe, write] {
        errno: -32,
        code: 'EPIPE',
        syscall: 'write'
      },
      expected: null,
      operator: 'ifError'
    }
  ...
@Trott Trott added the flaky-test Issues and PRs related to the tests with unstable failures on the CI. label Oct 30, 2020
@Trott
Copy link
Member Author

Trott commented Oct 30, 2020

https://ci.nodejs.org/job/node-test-commit-linux-containered/23143/nodes=ubuntu1804_sharedlibs_debug_x64/console

test-joyent-ubuntu1804_sharedlibs_container-x64-4

00:14:22 not ok 1292 parallel/test-http2-respond-file-error-pipe-offset
00:14:22   ---
00:14:22   duration_ms: 0.438
00:14:22   severity: fail
00:14:22   exitcode: 1
00:14:22   stack: |-
00:14:22     node:assert:885
00:14:22         throw newErr;
00:14:22         ^
00:14:22     
00:14:22     AssertionError [ERR_ASSERTION]: ifError got unwanted exception: EPIPE: broken pipe, write
00:14:22         at /home/iojs/build/workspace/node-test-commit-linux-containered/test/common/index.js:340:12
00:14:22         at /home/iojs/build/workspace/node-test-commit-linux-containered/test/common/index.js:377:15
00:14:22         at close (node:fs:1417:11)
00:14:22         at FSReqCallback.oncomplete (node:fs:171:23)
00:14:22      {
00:14:22       generatedMessage: false,
00:14:22       code: 'ERR_ASSERTION',
00:14:22       actual: [Error: EPIPE: broken pipe, write] {
00:14:22         errno: -32,
00:14:22         code: 'EPIPE',
00:14:22         syscall: 'write'
00:14:22       },
00:14:22       expected: null,
00:14:22       operator: 'ifError'
00:14:22     }
00:14:22   ...

@Trott Trott added the http2 Issues or PRs related to the http2 subsystem. label Oct 30, 2020
@Trott
Copy link
Member Author

Trott commented Oct 30, 2020

/ping @addaleax

@Trott
Copy link
Member Author

Trott commented Oct 30, 2020

/ping @tniessen Possibly a result of adding common.mustSucceed() recently? (Maybe that has uncovered a bug in the logic? Or maybe not. I'm doing a very superficial evaluation right now.)

@Trott
Copy link
Member Author

Trott commented Oct 30, 2020

Here's another one.

https://ci.nodejs.org/job/node-test-commit-plinux/35704/nodes=centos7-ppcle/console
test-osuosl-centos7-ppc64_le-2

00:08:00 not ok 1416 parallel/test-http2-respond-file-error-pipe-offset
00:08:00   ---
00:08:00   duration_ms: 0.146
00:08:00   severity: fail
00:08:00   exitcode: 1
00:08:00   stack: |-
00:08:00     node:assert:885
00:08:00         throw newErr;
00:08:00         ^
00:08:00     
00:08:00     AssertionError [ERR_ASSERTION]: ifError got unwanted exception: EPIPE: broken pipe, write
00:08:00         at /home/iojs/build/workspace/node-test-commit-plinux/nodes/centos7-ppcle/test/common/index.js:340:12
00:08:00         at /home/iojs/build/workspace/node-test-commit-plinux/nodes/centos7-ppcle/test/common/index.js:377:15
00:08:00         at close (node:fs:1417:11)
00:08:00         at FSReqCallback.oncomplete (node:fs:171:23)
00:08:00      {
00:08:00       generatedMessage: false,
00:08:00       code: 'ERR_ASSERTION',
00:08:00       actual: [Error: EPIPE: broken pipe, write] {
00:08:00         errno: -32,
00:08:00         code: 'EPIPE',
00:08:00         syscall: 'write'
00:08:00       },
00:08:00       expected: null,
00:08:00       operator: 'ifError'
00:08:00     }
00:08:00   ...

@Trott
Copy link
Member Author

Trott commented Oct 30, 2020

Last one for now.

https://ci.nodejs.org/job/node-test-commit-linuxone/23764/nodes=rhel7-s390x/consoleText
test-ibm-rhel7-s390x-4

not ok 1241 parallel/test-http2-respond-file-error-pipe-offset
  ---
  duration_ms: 0.67
  severity: fail
  exitcode: 1
  stack: |-
    node:assert:885
        throw newErr;
        ^
    
    AssertionError [ERR_ASSERTION]: ifError got unwanted exception: EPIPE: broken pipe, write
        at /home/iojs/build/workspace/node-test-commit-linuxone/nodes/rhel7-s390x/test/common/index.js:340:12
        at /home/iojs/build/workspace/node-test-commit-linuxone/nodes/rhel7-s390x/test/common/index.js:377:15
        at close (node:fs:1417:11)
        at FSReqCallback.oncomplete (node:fs:171:23)
     {
      generatedMessage: false,
      code: 'ERR_ASSERTION',
      actual: [Error: EPIPE: broken pipe, write] {
        errno: -32,
        code: 'EPIPE',
        syscall: 'write'
      },
      expected: null,
      operator: 'ifError'
    }
  ...

@tniessen
Copy link
Member

tniessen commented Oct 30, 2020

/ping @tniessen Possibly a result of adding common.mustSucceed() recently? (Maybe that has uncovered a bug in the logic? Or maybe not. I'm doing a very superficial evaluation right now.)

@Trott Good question! When I updated this test, I assumed the call to writeFile is expected to succeed, which doesn't always seem to be the case. The previous mustCall() callback simply ignored the error.

  1. If this error is expected to never occur, then switching to mustSucceed has uncovered a bug and we should investigate why this error occurs.
  2. If this error is expected to occur sometimes, we need to switch back to mustCall(), but should add an explaining comment and an assertion regarding the type/code of the error.
  3. If this error is expected to always occur, the test case should assert that it does.

MylesBorins added a commit to MylesBorins/node that referenced this issue Oct 30, 2020
This is now failing inconsistently across many platforms. This
appears to be the result of the addition of mustSucceed being
added to the test during testing refactoring.

We should mark flaky until we have figured out what the issue
is.

Refs: nodejs#35881
MylesBorins added a commit that referenced this issue Oct 30, 2020
This is now failing inconsistently across many platforms. This
appears to be the result of the addition of mustSucceed being
added to the test during testing refactoring.

We should mark flaky until we have figured out what the issue
is.

Refs: #35881

PR-URL: #35883
Reviewed-By: Tobias Nießen <[email protected]>
Reviewed-By: Gireesh Punathil <[email protected]>
targos pushed a commit that referenced this issue Nov 3, 2020
This is now failing inconsistently across many platforms. This
appears to be the result of the addition of mustSucceed being
added to the test during testing refactoring.

We should mark flaky until we have figured out what the issue
is.

Refs: #35881

PR-URL: #35883
Reviewed-By: Tobias Nießen <[email protected]>
Reviewed-By: Gireesh Punathil <[email protected]>
@Trott
Copy link
Member Author

Trott commented Nov 21, 2020

  • If this error is expected to never occur, then switching to mustSucceed has uncovered a bug and we should investigate why this error occurs.
  • If this error is expected to occur sometimes, we need to switch back to mustCall(), but should add an explaining comment and an assertion regarding the type/code of the error.
  • If this error is expected to always occur, the test case should assert that it does.

@addaleax Do you have any insight as to whether the error here should be expected to occur sometimes and can be ignored or not?

@Trott
Copy link
Member Author

Trott commented Nov 21, 2020

https://ci.nodejs.org/job/node-test-commit-linux/38406/nodes=alpine-latest-x64/consoleText

not ok 1267 parallel/test-http2-respond-file-error-pipe-offset # TODO : Fix flaky test
  ---
  duration_ms: 0.224
  severity: flaky
  exitcode: 1
  stack: |-
    node:assert:885
        throw newErr;
        ^
    
    AssertionError [ERR_ASSERTION]: ifError got unwanted exception: EPIPE: broken pipe, write
        at /home/iojs/build/workspace/node-test-commit-linux/nodes/alpine-latest-x64/test/common/index.js:340:12
        at /home/iojs/build/workspace/node-test-commit-linux/nodes/alpine-latest-x64/test/common/index.js:377:15
        at close (node:fs:1452:11)
        at FSReqCallback.oncomplete (node:fs:180:23)
     {
      generatedMessage: false,
      code: 'ERR_ASSERTION',
      actual: [Error: EPIPE: broken pipe, write] {
        errno: -32,
        code: 'EPIPE',
        syscall: 'write'
      },
      expected: null,
      operator: 'ifError'
    }
  ...

@Trott
Copy link
Member Author

Trott commented Nov 28, 2020

https://ci.nodejs.org/job/node-test-commit-linux/nodes=alpine-latest-x64/38508/consoleText

not ok 1267 parallel/test-http2-respond-file-error-pipe-offset # TODO : Fix flaky test
  ---
  duration_ms: 0.153
  severity: flaky
  exitcode: 1
  stack: |-
    node:assert:900
        throw newErr;
        ^
    
    AssertionError [ERR_ASSERTION]: ifError got unwanted exception: EPIPE: broken pipe, write
        at /home/iojs/build/workspace/node-test-commit-linux/nodes/alpine-latest-x64/test/common/index.js:340:12
        at /home/iojs/build/workspace/node-test-commit-linux/nodes/alpine-latest-x64/test/common/index.js:377:15
        at close (node:fs:1459:11)
        at FSReqCallback.oncomplete (node:fs:187:23)
     {
      generatedMessage: false,
      code: 'ERR_ASSERTION',
      actual: [Error: EPIPE: broken pipe, write] {
        errno: -32,
        code: 'EPIPE',
        syscall: 'write'
      },
      expected: null,
      operator: 'ifError'
    }
  ...

@Trott
Copy link
Member Author

Trott commented Nov 28, 2020

I'm able to replicate this locally on macOS by running many copies of the test at once:

$ tools/test.py -j96 --repeat 192 test/parallel/test-http2-respond-file-error-pipe-offset.js
=== release test-http2-respond-file-error-pipe-offset ===                     
Path: parallel/test-http2-respond-file-error-pipe-offset
node:assert:900
    throw newErr;
    ^

AssertionError [ERR_ASSERTION]: ifError got unwanted exception: EPIPE: broken pipe, write
    at /Users/trott/io.js/test/common/index.js:340:12
    at /Users/trott/io.js/test/common/index.js:377:15
    at close (node:fs:1459:11)
    at FSReqCallback.oncomplete (node:fs:187:23)
 {
  generatedMessage: false,
  code: 'ERR_ASSERTION',
  actual: [Error: EPIPE: broken pipe, write] {
    errno: -32,
    code: 'EPIPE',
    syscall: 'write'
  },
  expected: null,
  operator: 'ifError'
}
Command: out/Release/node /Users/trott/io.js/test/parallel/test-http2-respond-file-error-pipe-offset.js
=== release test-http2-respond-file-error-pipe-offset ===                     
Path: parallel/test-http2-respond-file-error-pipe-offset
node:assert:900
    throw newErr;
    ^

AssertionError [ERR_ASSERTION]: ifError got unwanted exception: EPIPE: broken pipe, write
    at /Users/trott/io.js/test/common/index.js:340:12
    at /Users/trott/io.js/test/common/index.js:377:15
    at close (node:fs:1459:11)
    at FSReqCallback.oncomplete (node:fs:187:23)
 {
  generatedMessage: false,
  code: 'ERR_ASSERTION',
  actual: [Error: EPIPE: broken pipe, write] {
    errno: -32,
    code: 'EPIPE',
    syscall: 'write'
  },
  expected: null,
  operator: 'ifError'
}
Command: out/Release/node /Users/trott/io.js/test/parallel/test-http2-respond-file-error-pipe-offset.js
=== release test-http2-respond-file-error-pipe-offset ===                     
Path: parallel/test-http2-respond-file-error-pipe-offset
node:assert:900
    throw newErr;
    ^

AssertionError [ERR_ASSERTION]: ifError got unwanted exception: EPIPE: broken pipe, write
    at /Users/trott/io.js/test/common/index.js:340:12
    at /Users/trott/io.js/test/common/index.js:377:15
    at close (node:fs:1459:11)
    at FSReqCallback.oncomplete (node:fs:187:23)
 {
  generatedMessage: false,
  code: 'ERR_ASSERTION',
  actual: [Error: EPIPE: broken pipe, write] {
    errno: -32,
    code: 'EPIPE',
    syscall: 'write'
  },
  expected: null,
  operator: 'ifError'
}
Command: out/Release/node /Users/trott/io.js/test/parallel/test-http2-respond-file-error-pipe-offset.js
[00:12|% 100|+ 189|-   3]: Done 
$

@Trott
Copy link
Member Author

Trott commented Nov 28, 2020

Because the test is sensitive to resources (based on #35881 (comment)) and it seems to be failing on the low-resource Alpine Linux, possible solutions (assuming the failure is expected in those situations) might be skip the test on low-resource machines or the dreaded move-to-sequential.

@Trott
Copy link
Member Author

Trott commented Nov 28, 2020

I think the situation we're in is this:

If this error is expected to occur sometimes, we need to switch back to mustCall(), but should add an explaining comment and an assertion regarding the type/code of the error.

It's possible for the reading end of the pipe to get the expected error
and break everything down before we're finished, so allow EPIPE but
no other errors.

Proposed fix: #36305

@Trott Trott closed this as completed in f178c5a Dec 7, 2020
danielleadams pushed a commit that referenced this issue Dec 7, 2020
cjihrig pushed a commit to cjihrig/node that referenced this issue Dec 8, 2020
BethGriggs pushed a commit that referenced this issue Dec 8, 2020
This is now failing inconsistently across many platforms. This
appears to be the result of the addition of mustSucceed being
added to the test during testing refactoring.

We should mark flaky until we have figured out what the issue
is.

Refs: #35881

PR-URL: #35883
Reviewed-By: Tobias Nießen <[email protected]>
Reviewed-By: Gireesh Punathil <[email protected]>
BethGriggs pushed a commit that referenced this issue Dec 10, 2020
This is now failing inconsistently across many platforms. This
appears to be the result of the addition of mustSucceed being
added to the test during testing refactoring.

We should mark flaky until we have figured out what the issue
is.

Refs: #35881

PR-URL: #35883
Reviewed-By: Tobias Nießen <[email protected]>
Reviewed-By: Gireesh Punathil <[email protected]>
BethGriggs pushed a commit that referenced this issue Dec 15, 2020
This is now failing inconsistently across many platforms. This
appears to be the result of the addition of mustSucceed being
added to the test during testing refactoring.

We should mark flaky until we have figured out what the issue
is.

Refs: #35881

PR-URL: #35883
Reviewed-By: Tobias Nießen <[email protected]>
Reviewed-By: Gireesh Punathil <[email protected]>
targos pushed a commit that referenced this issue Apr 25, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
flaky-test Issues and PRs related to the tests with unstable failures on the CI. http2 Issues or PRs related to the http2 subsystem.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants