-
Notifications
You must be signed in to change notification settings - Fork 30.3k
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
stream: allow stream to stay open after take #47023
base: main
Are you sure you want to change the base?
stream: allow stream to stay open after take #47023
Conversation
Review requested:
|
if (options?.destroyStream != null) { | ||
validateBoolean(options.destroyStream, 'options.destroyStream'); | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe another name would be better? Not sure what though... @benjamingr
lib/internal/streams/operators.js
Outdated
for await (const val of this.iterator({ destroyOnReturn: options?.destroyStream ?? true })) { | ||
if (options?.signal?.aborted) { | ||
throw new AbortError(); | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think that if the stream fails we should close the stream, WDYT @ronag ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@mcollina any thoughts on your side?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
after thinking I think it should be closed on an error as in the iterator helpers proposal spec the underlying iterator should be closed when it failed
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for opening a PR! Can you please add a unit test?
Docs are also missing |
Hey @mcollina I've added tests and docs :) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm
@mcollina is something holding this back from merging? Or we waiting for the TC39? |
we have 48 hours grace period to allow for folks across the globe to review |
Failed to start CI- Validating Jenkins credentials ✔ Jenkins credentials valid - Starting PR CI job ✘ Failed to start PR CI: 403 Forbiddenhttps://github.com/nodejs/node/actions/runs/4384604326 |
Failed to start CI- Validating Jenkins credentials ✔ Jenkins credentials valid - Starting PR CI job ✘ Failed to start PR CI: 403 Forbiddenhttps://github.com/nodejs/node/actions/runs/4385139704 |
Co-authored-by: Debadree Chatterjee <debadree333@gmail.com>
…fter-take-46980' into feat/allow_stream-to-stay-open-after-take-46980
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think you would need to remove the merge commit since supposedly it can cause issues with the tooling everything else is good!!
aren't we using squash and merge? |
Ref: #46910 (comment) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think discussion has exhausted itself in the spec issue and I don't want to deviate from it until we proved we must
Should be add the blocked label for now then? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah sorry I meant to explicitly block and hit the wrong button
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think what you really want is a chunk
(which will be proposed for inclusion in standard iterators in the future) or a nextN
helper like
function nextN(iterator, n) {
const result = [];
const next = iterator.next;
for (; n > 0; --n) {
cont { done, value } = next.call(iterator);
if (done) break;
result.push(value);
}
return result;
}
@michaelficarra no problem but maybe could you update the proposal first so we won't have this back and forth FYI I think nextN is better name than chunk |
@rluvaton |
Oh, after looking at chunk what I really want is Do you think that non-closing
|
Having
Example of usages: having it as an operator: const responses = await topVisitedUrlsIterator
.filter(noEmptyLine)
.drop(1) // Header
.nextN(8)
.map(parseLine)
.map(value => apiCall(value), { concurrency: 4 })
.toArray(); having it as a static function: const values = await nextN(
topVisitedUrlsIterator
.filter(noEmptyLine)
.drop(1),
8)
.map(parseLine);
// How would I use the concurrency that we would have in the map?
const responses = concurrentMap(values, (value) => apiCall(value), 4); |
# Conflicts: # lib/internal/streams/operators.js
fix #46980
TODO