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

http: client aborted should be boolean. #20230

Closed
wants to merge 1 commit into from

Conversation

ronag
Copy link
Member

@ronag ronag commented Apr 23, 2018

This is a semver-major.

Checklist
  • make -j4 test (UNIX), or vcbuild test (Windows) passes
  • tests and/or benchmarks are included
  • documentation is changed or added
  • commit message follows commit guidelines

@nodejs-github-bot nodejs-github-bot added the lib / src Issues and PRs related to general changes in the lib or src directory. label Apr 23, 2018
@ronag ronag changed the title Http client boolean aborted http: client aborted should be boolean. Apr 23, 2018
@vsemozhetbyt vsemozhetbyt added http Issues or PRs related to the http subsystem. http2 Issues or PRs related to the http2 subsystem. labels Apr 23, 2018
doc/api/http.md Outdated
@@ -1288,6 +1287,13 @@ the server, then sockets are destroyed when they time out. If a handler is
assigned to the request, the response, or the server's `'timeout'` events,
timed out sockets must be handled explicitly.

### response.aborted
Copy link
Contributor

Choose a reason for hiding this comment

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

This should go before ### response.addTrailers(headers) ABC-wise.

doc/api/http.md Outdated
<!-- YAML
added: REPLACEME
-->

Copy link
Contributor

Choose a reason for hiding this comment

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

Properties need explicit types documented, in this case:

* {boolean}

doc/api/http.md Outdated
added: REPLACEME
-->

If a request has been aborted.
Copy link
Contributor

Choose a reason for hiding this comment

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

Is it a typo or confusing API? response.aborted means request is aborted?

doc/api/http2.md Outdated
@@ -2918,6 +2918,13 @@ the server, then [`Http2Stream`]()s are destroyed when they time out. If a
handler is assigned to the request, the response, or the server's `'timeout'`
events, timed out sockets must be handled explicitly.

### response.aborted
Copy link
Contributor

Choose a reason for hiding this comment

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

  1. This should go before #### response.addTrailers(headers) ABC-wise.
  2. Heading level should be increased from ### to ####.

doc/api/http2.md Outdated
<!-- YAML
added: REPLACEME
-->

Copy link
Contributor

Choose a reason for hiding this comment

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

Properties need explicit types documented, in this case:

* {boolean}

doc/api/http2.md Outdated
added: REPLACEME
-->

If a request has been aborted.
Copy link
Contributor

Choose a reason for hiding this comment

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

Is it a typo or confusing API? response.aborted means request is aborted?

@ronag ronag force-pushed the http-client-boolean-aborted branch 3 times, most recently from f854fb7 to 01820dd Compare April 23, 2018 17:00
@ronag ronag mentioned this pull request Apr 23, 2018
3 tasks
doc/api/http.md Outdated

* {boolean}

<<<<<<< HEAD
Copy link
Contributor

@mscdex mscdex Apr 23, 2018

Choose a reason for hiding this comment

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

This should not have passed a make test. If it did, we need to update Makefile to fix the conflict detection.

Copy link
Member Author

@ronag ronag Apr 23, 2018

Choose a reason for hiding this comment

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

That was just me in a hurry. Apologies.

@ronag ronag force-pushed the http-client-boolean-aborted branch from 01820dd to 3711eb5 Compare April 23, 2018 17:34
@lpinca lpinca added the semver-major PRs that contain breaking changes and should be released in the next major version. label Apr 26, 2018
@lpinca
Copy link
Member

lpinca commented Apr 26, 2018

Why does this depend on #20094? #20094 works on http.IncomingMessage while this on http.ClientRequest. Can't we simply make the ClientRequest aborted property a boolean here?

@ronag
Copy link
Member Author

ronag commented Apr 26, 2018

@lpinca because of the test

@lpinca
Copy link
Member

lpinca commented Apr 26, 2018

Ok, I'm pretty sure we are already testing the aborted property on ClientRequest so maybe change the existing tests and keep the others for IncomingMessage ?

@lpinca
Copy link
Member

lpinca commented Apr 26, 2018

Like test/parallel/test-http-abort-stream-end.js seems a perfect candidate for this.

@ronag ronag force-pushed the http-client-boolean-aborted branch from 3711eb5 to 69d16fc Compare April 26, 2018 07:54
@ronag
Copy link
Member Author

ronag commented Apr 26, 2018

@lpinca fixed

@@ -48,11 +48,13 @@ server.listen(0, () => {
if (size > maxSize) {
aborted = true;
Copy link
Member

Choose a reason for hiding this comment

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

This can be removed, and the assertion above changed to assert.strictEqual(req.aborted, false);

Copy link
Member Author

Choose a reason for hiding this comment

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

Fixed

@ronag ronag force-pushed the http-client-boolean-aborted branch from 69d16fc to 0d5ccde Compare April 26, 2018 08:10
@lpinca
Copy link
Member

lpinca commented Apr 26, 2018

@lpinca lpinca removed http2 Issues or PRs related to the http2 subsystem. lib / src Issues and PRs related to general changes in the lib or src directory. labels Apr 26, 2018
@vsemozhetbyt
Copy link
Contributor

@ronag Can you rebase to resolve conflicts?

It seems we need two reviews from the @nodejs/tsc as this is semver-major.

@cjihrig
Copy link
Contributor

cjihrig commented May 3, 2018

Just out of curiosity, why is this change necessary/desirable?

@ronag ronag force-pushed the http-client-boolean-aborted branch from 0d5ccde to 793c2c3 Compare May 4, 2018 09:31
@ronag
Copy link
Member Author

ronag commented May 4, 2018

@cjihrig: performance and consistency

@vsemozhetbyt
Copy link
Contributor

@vsemozhetbyt
Copy link
Contributor

vsemozhetbyt commented May 8, 2018

Rerun one failed task: https://ci.nodejs.org/job/node-test-commit-freebsd/17576/ (green).

@vsemozhetbyt
Copy link
Contributor

@nodejs/tsc Please review as this is semver-major.

@vsemozhetbyt
Copy link
Contributor

@nodejs/tsc, how can we proceed with this PR?

@mcollina
Copy link
Member

@vsemozhetbyt this needs two @nodejs/tsc LGTMs to land.

@ronag can you please elaborate on performance and consistency? Why does this impact performance? Also, we are actually removing a functionality here.

This requires a CITGM to land.

CITGM (master): https://ci.nodejs.org/view/Node.js-citgm/job/citgm-smoker/1406/
CITGM (this PR): https://ci.nodejs.org/view/Node.js-citgm/job/citgm-smoker/1407/

@apapirovski
Copy link
Member

Calling Date.now is pretty damn slow so I would assume that's the performance part here. As for consistency, I think we added this property elsewhere where it's only a boolean (for the performance reasons). Personally, I'm +1 on this change.

* {boolean}

The `request.aborted` property will be `true` if the request has
been aborted.
Copy link
Member

Choose a reason for hiding this comment

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

Can you add a changes: block in the metadata for this property? (e.g. what we have for createServer() further below in the file)

Copy link
Member Author

Choose a reason for hiding this comment

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

Fixed

@lpinca
Copy link
Member

lpinca commented May 13, 2018

@mcollina for consistency see #20094.

Copy link
Member

@mcollina mcollina left a comment

Choose a reason for hiding this comment

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

LGTM

@ronag ronag force-pushed the http-client-boolean-aborted branch from 793c2c3 to 0995002 Compare May 13, 2018 17:19
changes:
- version: REPLACEME
pr-url: https://github.com/nodejs/node/pull/20230
description: The aborted property is no longer a timestamp number.
Copy link
Contributor

Choose a reason for hiding this comment

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

Nit: aborted -> `aborted`?

@vsemozhetbyt
Copy link
Contributor

vsemozhetbyt commented May 14, 2018

We have 2 approvements from the TSC, so this is the final CI:
https://ci.nodejs.org/job/node-test-pull-request/14864/

I will land soon if there are no objections and CI is green (I can fix the doc nit on landing).

vsemozhetbyt pushed a commit that referenced this pull request May 14, 2018
PR-URL: #20230
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
@vsemozhetbyt
Copy link
Contributor

Landed in 4b00c4f
Thank you!

@Trott Trott added the notable-change PRs with changes that should be highlighted in changelogs. label May 14, 2018
mastermatt added a commit to mastermatt/nock that referenced this pull request Mar 24, 2020
Nocks behavior around events and errors relating to aborting and ending requests has not lined up
with Node for while. I dug into an investigation of how it differs, if there were git commits/pull-requests explaining why they differ,
and trying to answer the question of should Nock change to line up better.

The single largest deviation were the errors emitted around aborting or already aborted requests.
Emitting an error on abort was added to fix issue nock#439.
The conversation talks about how Node emits an error post abort.
> ... in practice the `http` module does emit an `ECONNRESET` error after aborting. ... - Jan 7, 2016

However, this is only true between the 'socket' and 'response' events.
Otherwise calling abort does not emit an error of any kind.

Determining exactly what Nock should do is a bit of moving target.
As Node's internals of HTTP, Net, Stream, and micro task timing have changed a lot since
iojs/v4, when Nock added these errors, and v13, current at this time.

My conclusion is that none of Nock's deviations from Node's _documented_ behavior
are user features that should be maintained. If anything, bringing Nock closer to Node
better fulfills original requests.
nock#282

The entire `test_abort.js` file was scraped and rewritten by writing assertions against Node behavior, without Nock first.
Then adding Nock into each test to ensure events and errors were correct.

BREAKING CHANGE:

Calling `request.abort()`:
- Use to always emit a 'socket hang up' error. Now only emits the error if `abort` is called between the 'socket' and 'response' events.
- The emitted 'abort' event now happens on `nextTick`.
- The socket is now only destroyed if the 'socket' event has fired, and now emits a 'close' event on `nextTick` that propagates though the request object.
- `request.aborted` attribute is set to `true` instead of a timestamp. Changed in Node v11.0 nodejs/node#20230

Calling `write`, `end`, or `flushHeaders` on an aborted request no longer emits an error.
However, writing to a request that is already finished (ended) will emit a 'write after end' error.

Playback of a mocked responses will now never happen until the 'socket' event is emitted.
The 'socket' event is still artificially set to emit on `nextTick` when a ClientRequest is created.
This means in the following code the Scope will never be done because at least one tick needs
to happen before any matched Interceptor is considered consumed.
```js
const scope = nock(...).get('/').reply()
const req = http.get(...)
scope.done()
```
mastermatt added a commit to mastermatt/nock that referenced this pull request Mar 29, 2020
Nocks behavior around events and errors relating to aborting and ending requests has not lined up
with Node for while. I dug into an investigation of how it differs, if there were git commits/pull-requests explaining why they differ,
and trying to answer the question of should Nock change to line up better.

The single largest deviation were the errors emitted around aborting or already aborted requests.
Emitting an error on abort was added to fix issue nock#439.
The conversation talks about how Node emits an error post abort.
> ... in practice the `http` module does emit an `ECONNRESET` error after aborting. ... - Jan 7, 2016

However, this is only true between the 'socket' and 'response' events.
Otherwise calling abort does not emit an error of any kind.

Determining exactly what Nock should do is a bit of moving target.
As Node's internals of HTTP, Net, Stream, and micro task timing have changed a lot since
iojs/v4, when Nock added these errors, and v13, current at this time.

My conclusion is that none of Nock's deviations from Node's _documented_ behavior
are user features that should be maintained. If anything, bringing Nock closer to Node
better fulfills original requests.
nock#282

The entire `test_abort.js` file was scraped and rewritten by writing assertions against Node behavior, without Nock first.
Then adding Nock into each test to ensure events and errors were correct.

BREAKING CHANGE:

Calling `request.abort()`:
- Use to always emit a 'socket hang up' error. Now only emits the error if `abort` is called between the 'socket' and 'response' events.
- The emitted 'abort' event now happens on `nextTick`.
- The socket is now only destroyed if the 'socket' event has fired, and now emits a 'close' event on `nextTick` that propagates though the request object.
- `request.aborted` attribute is set to `true` instead of a timestamp. Changed in Node v11.0 nodejs/node#20230

Calling `write`, `end`, or `flushHeaders` on an aborted request no longer emits an error.
However, writing to a request that is already finished (ended) will emit a 'write after end' error.

Playback of a mocked responses will now never happen until the 'socket' event is emitted.
The 'socket' event is still artificially set to emit on `nextTick` when a ClientRequest is created.
This means in the following code the Scope will never be done because at least one tick needs
to happen before any matched Interceptor is considered consumed.
```js
const scope = nock(...).get('/').reply()
const req = http.get(...)
scope.done()
```
mastermatt added a commit to nock/nock that referenced this pull request Apr 4, 2020
Nocks behavior around events and errors relating to aborting and ending requests has not lined up
with Node for while. I dug into an investigation of how it differs, if there were git commits/pull-requests explaining why they differ,
and trying to answer the question of should Nock change to line up better.

The single largest deviation were the errors emitted around aborting or already aborted requests.
Emitting an error on abort was added to fix issue #439.
The conversation talks about how Node emits an error post abort.
> ... in practice the `http` module does emit an `ECONNRESET` error after aborting. ... - Jan 7, 2016

However, this is only true between the 'socket' and 'response' events.
Otherwise calling abort does not emit an error of any kind.

Determining exactly what Nock should do is a bit of moving target.
As Node's internals of HTTP, Net, Stream, and micro task timing have changed a lot since
iojs/v4, when Nock added these errors, and v13, current at this time.

My conclusion is that none of Nock's deviations from Node's _documented_ behavior
are user features that should be maintained. If anything, bringing Nock closer to Node
better fulfills original requests.
#282

The entire `test_abort.js` file was scraped and rewritten by writing assertions against Node behavior, without Nock first.
Then adding Nock into each test to ensure events and errors were correct.

BREAKING CHANGE:

Calling `request.abort()`:
- Use to always emit a 'socket hang up' error. Now only emits the error if `abort` is called between the 'socket' and 'response' events.
- The emitted 'abort' event now happens on `nextTick`.
- The socket is now only destroyed if the 'socket' event has fired, and now emits a 'close' event on `nextTick` that propagates though the request object.
- `request.aborted` attribute is set to `true` instead of a timestamp. Changed in Node v11.0 nodejs/node#20230

Calling `write`, `end`, or `flushHeaders` on an aborted request no longer emits an error.
However, writing to a request that is already finished (ended) will emit a 'write after end' error.

Playback of a mocked responses will now never happen until the 'socket' event is emitted.
The 'socket' event is still artificially set to emit on `nextTick` when a ClientRequest is created.
This means in the following code the Scope will never be done because at least one tick needs
to happen before any matched Interceptor is considered consumed.
```js
const scope = nock(...).get('/').reply()
const req = http.get(...)
scope.done()
```
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
http Issues or PRs related to the http subsystem. notable-change PRs with changes that should be highlighted in changelogs. semver-major PRs that contain breaking changes and should be released in the next major version.
Projects
None yet
Development

Successfully merging this pull request may close these issues.