Skip to content

Conversation

@trevnorris
Copy link
Contributor

@trevnorristrevnorris commented Jun 29, 2017

Checklist
  • make -j4 test (UNIX), or vcbuild test (Windows) passes
  • tests and/or benchmarks are included
  • commit message follows commit guidelines
Affected core subsystem(s)

test

Description

If TTY isn't available then the test will always fail.

Fixes: #13984

CI: https://ci.nodejs.org/job/node-test-pull-request/8879/

@trevnorristrevnorris requested a review from addaleaxJune 29, 2017 21:23
@nodejs-github-botnodejs-github-bot added async_hooks Issues and PRs related to the async hooks subsystem. test Issues and PRs related to the tests. labels Jun 29, 2017
Copy link
Member

@addaleaxaddaleax left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, but at some point I’d like it if we could split up the async_hooks test directory and move these to the pseudo-tty tests

@trevnorris
Copy link
ContributorAuthor

trevnorris commented Jul 3, 2017

@refack This conflicted with test-ttywrap.readstream.js from 372b85d. I made the change of how the tty fd is found to match test-ttywrap.writestream.js.

CI: https://ci.nodejs.org/job/node-test-commit/10936/

@refack
Copy link
Contributor

@refack This conflicted with test-ttywrap.readstream.js from 372b85d. I made the change of how the tty fd is found to match test-ttywrap.writestream.js.

New code works here (on Windows), but I see you have problems in linux

not ok 42 async-hooks/test-ttywrap.readstream --- duration_ms: 0.57 severity: fail stack: |- assert.js:55 throw new errors.AssertionError({^ AssertionError [ERR_ASSERTION]: null !== null at Object.<anonymous> (/data/iojs/build/workspace/node-test-commit-linuxone/nodes/rhel72-s390x/test/async-hooks/test-ttywrap.readstream.js:19:8) at Module._compile (module.js:569:30) at Object.Module._extensions..js (module.js:580:10) at Module.load (module.js:503:32) at tryModuleLoad (module.js:466:12) at Function.Module._load (module.js:458:3) at Function.Module.runMain (module.js:605:10) at startup (bootstrap_node.js:158:16) at bootstrap_node.js:575:3 ... ok 43 async-hooks/test-querywrap --- duration_ms: 0.265 ... not ok 44 async-hooks/test-ttywrap.writestream --- duration_ms: 0.75 severity: fail stack: |- assert.js:55 throw new errors.AssertionError({^ AssertionError [ERR_ASSERTION]: null !== null at Object.<anonymous> (/data/iojs/build/workspace/node-test-commit-linuxone/nodes/rhel72-s390x/test/async-hooks/test-ttywrap.writestream.js:19:8) at Module._compile (module.js:569:30) at Object.Module._extensions..js (module.js:580:10) at Module.load (module.js:503:32) at tryModuleLoad (module.js:466:12) at Function.Module._load (module.js:458:3) at Function.Module.runMain (module.js:605:10) at startup (bootstrap_node.js:158:16) at bootstrap_node.js:575:3 ... 

https://ci.nodejs.org/job/node-test-commit-linuxone/7060/nodes=rhel72-s390x/console

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This i'm not in love with... does require('tty') have significant side effects?

Copy link
ContributorAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hm. Reason I return null here then check it below is because I'd have imagined that common.getTTYfd() should only return a positive number if there's a valid fd for the TTY. Thus ReadStream/WriteStream shouldn't fail. Appears that isn't always the case. So I'll go back to the null check and early return.

I will defend the use of getTTYfd(), which also does a require('tty') when called. So I'm not worried about the possible side effects of calling it here.

Copy link
Contributor

@refackrefackJul 5, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So if we don't fear side effect, why not move the require to the top?
The invoked lambda I understand (return null and assign to const is very functional-programing, and I like 👍 )

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ohh here it is again.

@refack
Copy link
Contributor

Is it easy to parameterize and merge these two?

@trevnorris
Copy link
ContributorAuthor

@refack

Is it easy to parameterize and merge these two?

Probably. If not in this PR I'll add another that merges them later.

@trevnorris
Copy link
ContributorAuthor

trevnorris commented Jul 6, 2017

@refack Don't know why I didn't think of the fact that process.{stdin,stdout} are already setup for this. Made changes and running CI again.

CI: https://ci.nodejs.org/job/node-test-commit/10980/

If TTY isn't available then the test will always fail. Also use the already available process.stdin instead of opening another ReadStream. Fixes: nodejs#13984 PR-URL: nodejs#13991
Match changes made to test-ttywrap.readstream for consistency. PR-URL: nodejs#13991
Copy link
Contributor

@refackrefack left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

K.I.S.S. FTW!

@AndreasMadsen
Copy link
Member

Anything preventing this from landing?

@refack
Copy link
Contributor

Anything preventing this from landing?

I believe just etiquette, to customarily let Collaborators land their own PRs 🤷‍♂️
CI was green, so LGTM.

@AndreasMadsen
Copy link
Member

I believe just etiquette, to customarily let Collaborators land their own PRs.

That is why I asked :)

@jasnell
Copy link
Member

I believe just etiquette, to customarily let Collaborators land their own PRs.

Yes and no. Anyone should feel free to land any PR that is ready to land, particularly ones that are more or less trivial. For PRs that are more involved, then yes, it's best to let the authoring contributor land as they have the best context to know when it's ready to go.

refack pushed a commit to refack/node that referenced this pull request Jul 12, 2017
If TTY isn't available then the test will always fail. Also use the already available process.stdin instead of opening another ReadStream. PR-URL: nodejs#13991Fixes: nodejs#13984 Reviewed-By: Anna Henningsen <[email protected]> Reviewed-By: James M Snell <[email protected]> Reviewed-By: Refael Ackermann <[email protected]>
refack pushed a commit to refack/node that referenced this pull request Jul 12, 2017
Match changes made to test-ttywrap.readstream for consistency. PR-URL: nodejs#13991Fixes: nodejs#13984 Reviewed-By: Anna Henningsen <[email protected]> Reviewed-By: James M Snell <[email protected]> Reviewed-By: Refael Ackermann <[email protected]>
@refack
Copy link
Contributor

Since @trevnorris is busy with another PR, and I'm pretty aware of the context:
Landed in 3b4010b250d50b

@refackrefack closed this Jul 12, 2017
@trevnorris
Copy link
ContributorAuthor

@refack Thanks for landing this.

@addaleaxaddaleax mentioned this pull request Jul 18, 2017
addaleax pushed a commit that referenced this pull request Jul 18, 2017
If TTY isn't available then the test will always fail. Also use the already available process.stdin instead of opening another ReadStream. PR-URL: #13991Fixes: #13984 Reviewed-By: Anna Henningsen <[email protected]> Reviewed-By: James M Snell <[email protected]> Reviewed-By: Refael Ackermann <[email protected]>
addaleax pushed a commit that referenced this pull request Jul 18, 2017
Match changes made to test-ttywrap.readstream for consistency. PR-URL: #13991Fixes: #13984 Reviewed-By: Anna Henningsen <[email protected]> Reviewed-By: James M Snell <[email protected]> Reviewed-By: Refael Ackermann <[email protected]>
Fishrock123 pushed a commit that referenced this pull request Jul 19, 2017
If TTY isn't available then the test will always fail. Also use the already available process.stdin instead of opening another ReadStream. PR-URL: #13991Fixes: #13984 Reviewed-By: Anna Henningsen <[email protected]> Reviewed-By: James M Snell <[email protected]> Reviewed-By: Refael Ackermann <[email protected]>
Fishrock123 pushed a commit that referenced this pull request Jul 19, 2017
Match changes made to test-ttywrap.readstream for consistency. PR-URL: #13991Fixes: #13984 Reviewed-By: Anna Henningsen <[email protected]> Reviewed-By: James M Snell <[email protected]> Reviewed-By: Refael Ackermann <[email protected]>
Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Labels

async_hooksIssues and PRs related to the async hooks subsystem.testIssues and PRs related to the tests.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants

@trevnorris@refack@AndreasMadsen@jasnell@addaleax@nodejs-github-bot