Further fixes an issue with the async iterator example where an
incorrect assumption was made in regards that drain or error
is always invoked after !write().
Fixes: https://github.com/nodejs/node/issues/31365
PR-URL: https://github.com/nodejs/node/pull/31367
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
The exact context of invocation of _writev API is not well known.
Also, the choice between _write and _writev is not well known.
Add a description to make it explicit.
Fixes: https://github.com/nodejs/node/issues/28408
Refs: https://github.com/nodejs/node/pull/28690
Co-authored-by: Parker Bjur <bjur.parker45@gmail.com>
PR-URL: https://github.com/nodejs/node/pull/31356
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Rich Trott <rtrott@gmail.com>
The for await loop into writable loop could cause an unhandled exception
in the case where we are waiting for data from the async iterable and
this no `'error'` handler is registered on the writable.
Fixes: https://github.com/nodejs/node/issues/31222
PR-URL: https://github.com/nodejs/node/pull/31252
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: Rich Trott <rtrott@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
errorOrDestroy emits 'error' synchronously due to
compat reasons. However, it should be possible to
use correct async behaviour for new code.
PR-URL: https://github.com/nodejs/node/pull/29744
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Rich Trott <rtrott@gmail.com>
The syntax of the sentence describing the role of writable.cork() was
unclear. This rephrase aims to make the distinction between writing
to the buffer and draining immediately to the underlying destination
clearer - while keeping performance considerations clearly in mind.
PR-URL: https://github.com/nodejs/node/pull/30442
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Denys Otrishko <shishugi@gmail.com>
MAX_HWM was added in 9208c89 where the highwatermark was changed to
always increase in steps of highest power of 2 to prevent increasing
hwm excessivly in tiny amounts.
Why a limit was added on the highwatermark is unclear but breaks
existing usage where a larger read size is used. The invariant for
read(n) is that a buffer of size n is always returned. Considering
a maximum ceiling on the buffer size breaks this invariant.
This PR significantly increases the limit to make it less likely to
break the previous invariant and also documents the limit.
Fixes: https://github.com/nodejs/node/issues/29933
PR-URL: https://github.com/nodejs/node/pull/29938
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
PR-URL: https://github.com/nodejs/node/pull/29012
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Instead of telling someone "It is important to do X", just tell them to
"Do X."
PR-URL: https://github.com/nodejs/node/pull/30108
Reviewed-By: Michael Dawson <michael_dawson@ca.ibm.com>
Reviewed-By: Trivikram Kamat <trivikr.dev@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Gireesh Punathil <gpunathi@in.ibm.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
The use of dashes -- in general, but especially in our docs -- can be
problematic. It is used inconsistently and there is always another form
of punctuation that is as good or better for the situation. In an effort
to reduce the number of variations we use to display the same types of
information, remove the various uses of dashes from the documentation.
PR-URL: https://github.com/nodejs/node/pull/30101
Reviewed-By: Gireesh Punathil <gpunathi@in.ibm.com>
Reviewed-By: Richard Lau <riclau@uk.ibm.com>
Reviewed-By: Trivikram Kamat <trivikr.dev@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
It is a common and unfortunate pattern to simply just forward
any and all options into the base constructor without taking
into account whether these options might conflict with basic
stream assumptions.
PR-URL: https://github.com/nodejs/node/pull/29857
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
Use explicit trailing `[]` for reference markdown links to prevent
implicit links when references are added to documents.
PR-URL: https://github.com/nodejs/node/pull/29808
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
Reviewed-By: David Carlier <devnexen@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Ensure the callback is always invoked before emitting
the error in both sync and async case.
PR-URL: https://github.com/nodejs/node/pull/29293
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Ensure the callback is always invoked before emitting
the error in both sync and async case.
PR-URL: https://github.com/nodejs/node/pull/29293
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
When implementing _writev, _write should be optional.
PR-URL: https://github.com/nodejs/node/pull/29639
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Minwoo Jung <minwoo@nodesource.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
In `.end()` methods, an optional `encoding` parameter makes sense
only if the `data` (`chunk`) parameter is provided.
PR-URL: https://github.com/nodejs/node/pull/29615
Reviewed-By: David Carlier <devnexen@gmail.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: Trivikram Kamat <trivikr.dev@gmail.com>
After 'error' only 'close' should be emitted.
PR-URL: https://github.com/nodejs/node/pull/28979
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Update writable stream code example using async iterator to use safer
`finished()` method instead of a `finish` event to avoid uncaught
exceptions
Fixes: https://github.com/nodejs/node/issues/29397
PR-URL: https://github.com/nodejs/node/pull/29425
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: Trivikram Kamat <trivikr.dev@gmail.com>
This is the document formation, because `node` is a command to be
executed, we should reguard it as a command prompt instead of a command
txt type.
PR-URL: https://github.com/nodejs/node/pull/29389
Reviewed-By: Rich Trott <rtrott@gmail.com>
Reviewed-By: Trivikram Kamat <trivikr.dev@gmail.com>
Notable changes:
* crypto:
* Added an oaepHash option to asymmetric encryption which allows
users to specify a hash function when using OAEP padding.
https://github.com/nodejs/node/pull/28335
* deps:
* Updated V8 to 7.6.303.29. https://github.com/nodejs/node/pull/28955
* Improves the performance of various APIs such as `JSON.parse` and
methods called on frozen arrays.
* Adds the Promise.allSettled method.
* Improves support of `BigInt` in `Intl` methods.
* For more information: https://v8.dev/blog/v8-release-76
* Updated libuv to 1.31.0. https://github.com/nodejs/node/pull/29070
* `UV_FS_O_FILEMAP` has been added for faster access to memory
mapped files on Windows.
* `uv_fs_mkdir()` now returns `UV_EINVAL` for invalid filenames on
Windows. It previously returned `UV_ENOENT`.
* The `uv_fs_statfs()` API has been added.
* The `uv_os_environ()` and `uv_os_free_environ()` APIs have been
added.
* fs:
* Added `fs.writev`, `fs.writevSync` and `filehandle.writev` (promise
version) methods. They allow to write an array of `ArrayBufferView`s
to a file descriptor. https://github.com/nodejs/node/pull/25925https://github.com/nodejs/node/pull/29186
* http:
* Added three properties to `OutgoingMessage.prototype`:
`writableObjectMode`, `writableLength` and `writableHighWaterMark`
https://github.com/nodejs/node/pull/29018
* stream:
* Added an new property `readableEnded` to readable streams. Its value
is set to `true` when the `'end'` event is emitted.
https://github.com/nodejs/node/pull/28814
* Added an new property `writableEnded` to writable streams. Its value
is set to `true` after `writable.end()` has been called.
https://github.com/nodejs/node/pull/28934
PR-URL: https://github.com/nodejs/node/pull/29210
This is work towards resolving the response.finished confusion and
future deprecation.
Note that implementation-wise, streams have both an ending and ended
state. However, in this case (in order to avoid confusion in user space)
writableEnded is equal to writable.ending. The ending vs ended situation
is internal state required for internal stream logic.
PR-URL: https://github.com/nodejs/node/pull/28934
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: Trivikram Kamat <trivikr.dev@gmail.com>
Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>
Reviewed-By: Rich Trott <rtrott@gmail.com>
Clarifies that creating multiple async iterators from the same stream
can lead to event listener leak.
PR-URL: https://github.com/nodejs/node/pull/28997
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: Trivikram Kamat <trivikr.dev@gmail.com>
readable.unshift() also allows to pass null and end stream
PR-URL: https://github.com/nodejs/node/pull/28953
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Rich Trott <rtrott@gmail.com>
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
