镜像站点 · 本页由第三方 GitHub 只读镜像提供，非 GitHub 官方站点，不接受任何登录或凭据输入。前往 github.com
Skip to content

[v6.x] test: investigate test-fs-read-buffer-tostring-fail #14430

Closed
Closed
[v6.x] test: investigate test-fs-read-buffer-tostring-fail#14430
Labels
bufferIssues and PRs related to the buffer subsystem.flaky-testIssues and PRs involving tests that fail intermittently in CI.fsIssues and PRs related to file-system APIs and the fs module.streamIssues and PRs related to Node.js streams.testIssues and PRs related to Node.js core tests and test infrastructure.

Description

@refack
refack
opened on Jul 22, 2017
  • Version: v6.x-staging
  • Platform: macOS
  • Subsystem: test
not ok 386 parallel/test-fs-read-buffer-tostring-fail
  ---
  duration_ms: 61.861
  severity: fail
  stack: |-
    timeout
  ...

https://ci.nodejs.org/job/node-test-commit-osx/11278/nodes=osx1010/

Activity

  1. refack
    added
    bufferIssues and PRs related to the buffer subsystem.
    flaky-testIssues and PRs involving tests that fail intermittently in CI.
    fsIssues and PRs related to file-system APIs and the fs module.
    streamIssues and PRs related to Node.js streams.
    testIssues and PRs related to Node.js core tests and test infrastructure.
    on Jul 22, 2017

  2. refack commented on Jul 22, 2017

    @refack
    refack
    on Jul 22, 2017
    ContributorAuthor

    Test file - https://github.com/nodejs/node/blob/v6.x-staging/test/parallel/test-fs-read-buffer-tostring-fail.js
    /cc @nodejs/platform-macos @nodejs/streams @nodejs/buffer

  3. mcollina commented on Jul 24, 2017

    @mcollina
    mcollina
    on Jul 24, 2017
    SponsorMember

    @refack I don't think it's possible to not have this test as flaky. We are generating a very big file on memory, then we try to save that extremely big file on disk, and then load it. Everything can happen in all this I/O and GC() activity.

    However, one thing we can do: convert https://github.com/nodejs/node/blob/v6.x-staging/test/parallel/test-fs-read-buffer-tostring-fail.js#L29-L33 into the pattern as the end of the https://nodejs.org/api/stream.html#stream_writable_write_chunk_encoding_callback (the one using the 'drain' event). That would reduce memory allocation on the Node.js process during the setup phase.

    I'm happy to review a PR that addresses this issue, and I think it would be good for someone that wants to improve their streams knowledge.

  4. refack commented on Jul 24, 2017

    @refack
    refack
    on Jul 24, 2017
    ContributorAuthor

    Also in the worse case, could create a PR adding

    test-fs-read-buffer-tostring-fail      : PASS,FLAKY

    to https://github.com/nodejs/node/blob/v6.x-staging/test/parallel/parallel.status#L7

  5. refack
    added
    good first issueIssues that are suitable for first-time contributors.
    on Jul 24, 2017

  6. Jeyanthinath commented on Jul 25, 2017

    @Jeyanthinath
    Jeyanthinath
    on Jul 25, 2017
    Contributor

    Can I take and contribute to this ?

  7. bnoordhuis commented on Jul 25, 2017

    @bnoordhuis
    bnoordhuis
    on Jul 25, 2017
    Member

    @Jeyanthinath Go for it.

  8. Trott
    removed
    good first issueIssues that are suitable for first-time contributors.
    on Jul 25, 2017
  9. refack
    added
    wipIssues and PRs that are still a work in progress.
    on Jul 25, 2017

  10. Jeyanthinath commented on Jul 25, 2017

    @Jeyanthinath
    Jeyanthinath
    on Jul 25, 2017
    Contributor

    PR #14472 ( deleted )

  11. Jeyanthinath commented on Jul 26, 2017

    @Jeyanthinath
    Jeyanthinath
    on Jul 26, 2017
    Contributor

    New PR #14495

  12. Trott commented on Jul 26, 2017

    @Trott
    Trott
    on Jul 26, 2017
    Member

    I don't think it's possible to not have this test as flaky.

    If the test is necessarily flaky on 6.x, then I'm not sure it makes sense to mark it as flaky on 6.x. By marking it as flaky, the results will always be ignored. For a test where there's a chance of fixing the issue, that's fine.

    For a test where there's no possible fix and/or no intention of fixing, it may be better to remove the test rather than have a test whose results are ignored.

    Or if the test is minimally flaky, then leave the status alone. You'll get red once in a month or whatever, but if it starts going red 100% of the time, you'll know something is (probably) broken.

    Not a blocking objection on the "mark as flaky" approach. Just suggestions. Feel free to proceed with the current plan if you disagree.

  13. Trott commented on Jul 26, 2017

    @Trott
    Trott
    on Jul 26, 2017
    Member

    Oh, not sure it's reasonable if the test is resource-intensive, but another option would be to program in a retry into the test before deciding the test has failed. Not great, but probably better than not having a test or having a test whose failures are discounted.

  14. refack commented on Jul 27, 2017

    @refack
    refack
    on Jul 27, 2017
    ContributorAuthor

    If the test is necessarily flaky on 6.x, then I'm not sure it makes sense to mark it as flaky on 6.x. By marking it as flaky, the results will always be ignored. For a test where there's a chance of fixing the issue, that's fine.

    IMHO yellow ⚠️ is better than ❌. It communicates that something it sort of wrong, and if it becomes consistent, it will get investigated. Red just makes people dig, find it's unrelated, and lose faith in the CI.

    I do agree that it the test could be rewritten to stabilize it, that is the better option in the longer term.

  15. mcollina commented on Aug 1, 2017

    @mcollina
    mcollina
    on Aug 1, 2017
    SponsorMember

    Considering the fact that the test is gone from master as it is targeting a deprecated API, I'm definitely 👍 in flagging it as flaky.

  16. refack
    added a commit that references this issue on Aug 1, 2017

    test: mark test-fs-read-buffer-to-string-fail as flaky

    0b012a6
  17. MylesBorins
    added 3 commits that reference this issue on Aug 14, 2017

    test: mark test-fs-read-buffer-to-string-fail as flaky

    0ae4c46

    test: mark test-fs-read-buffer-to-string-fail as flaky

    ee98df8

    test: mark test-fs-read-buffer-to-string-fail as flaky

    202bfcc
  18. maclover7
    added
    v6.x
    and removed
    wipIssues and PRs that are still a work in progress.
    on Dec 24, 2017

  19. apapirovski commented on Apr 12, 2018

    @apapirovski
    apapirovski
    on Apr 12, 2018
    Contributor

    As far as I can tell this has been resolved by marking it as flaky. Closing.

  20. apapirovski
    closed this as completedon Apr 12, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    bufferIssues and PRs related to the buffer subsystem.flaky-testIssues and PRs involving tests that fail intermittently in CI.fsIssues and PRs related to file-system APIs and the fs module.streamIssues and PRs related to Node.js streams.testIssues and PRs related to Node.js core tests and test infrastructure.

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions