Skip to content

stream: handling invalid stream arguments in stream.pipeline() #55305

@Renegade334

Description

@Renegade334

A few "what goes where"-related inconsistencies with stream.pipeline(). Validation of stream objects is very hit-and-miss:

Passing this: as this: should do this: and does this:
Non-readable Node stream source Should be rejected. Passes validation. Gets passed to Duplex.from(), resulting in a write-only Duplex. The pipeline will never receive any data.
transform Should be rejected. ✔️ Fails validation.
destination Should be accepted. ✔️ Passes validation.
Non-writable Node stream source Should be accepted. ✔️ Passes validation.
transform Should be rejected. Passes validation. Fails asynchronously at runtime: when the previous stream in the pipeline emits data, raises a TypeError due to attempting to call missing Writable methods.
destination Should be rejected. ❌ Same as above.
ReadableStream source Should be accepted. ✔️ Passes validation.
transform Should be rejected. ✔️ Fails validation.
destination Should be rejected. Passes validation. Fails asynchronously at runtime: raises a TypeError due to attempting to call the missing getWriter() method.
TransformStream source Undocumented, but should be accepted. ✔️ Passes validation.
transform Should be accepted. ✔️ Passes validation.
destination Undocumented, but should be accepted. ✔️ Passes validation.
WritableStream source Should be rejected. Passes validation. Gets passed to Duplex.from(), resulting in a write-only Duplex. The pipeline will never receive any data.
transform Should be rejected. ✔️ Fails validation.
destination Should be accepted. ✔️ Passes validation.

These should probably be validated consistently.

Other observations:

  • The docs should specify that TransformStreams are valid source and destination streams, as well as valid return values.
  • The transform validation error message doesn't specify which parameter failed validation, which is a pain in terms of debugging. Its counterparts in stream.compose() pass the parameter name to the error constructor as streams[n], which would be a fairly straightforward improvement.

Metadata

Metadata

Assignees

No one assigned

    Labels

    streamIssues and PRs related to the stream subsystem.

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions