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

unshift stream support #452

Closed
twiggy opened this issue May 3, 2021 · 2 comments
Closed

unshift stream support #452

twiggy opened this issue May 3, 2021 · 2 comments

Comments

@twiggy
Copy link

twiggy commented May 3, 2021

A few issues have pointed out that the stream becomes broken\altered after to fromStream is called.

its a pretty serious side effect that wouldn't be obvious at all.

we are currently working around this issue by calling stream.read(xxxx) and then stream.unshift. Maybe unshift could be an argument to stream.read() ... or maybe the chunk read could be passed back.

For us we get a stream from the http request, want to detect file type, but then immediately need to pass the stream to AWS's s3 sdk ... bit weird and we could probably just write the file, but unshift seems to work for now.

let leadingChunk = stream.read(4100);
let {ext, mime} = await fileType.fromBuffer(leadingChunk);
stream.unshift(leadingChunk);
@Borewit
Copy link
Collaborator

Borewit commented May 4, 2021

A few issues have pointed out that the stream becomes broken\altered after to fromStream is called.

I think you mean that the concept of a stream has been misunderstood in other issues. fromStream reads from a stream, and then the stream get (partially) consumed. That is how streams work.

At the same time, I do understand the desire to peek ahead on stream, determine the right file type from the stream, and read from the stream as if nothing happened. For that use case stream(readableStream) has been designed. Which is very similar to the example you provided. You directly see limitations, how much data will you buffer (this should be better documented, need to finalize #434).

Related:

For us we get a stream from the http request, want to detect file type, but then immediately need to pass the stream to AWS's s3 sdk ... bit weird and we could probably just write the file, but unshift seems to work for now.

Writing the file first sounds like a reasonable solution to me. You simply do not know how much of the file you need to determine it's file type. The fact that we can determine the file type for many files with the very first few bytes, does not take away the fact that for some files we need much more data.

@Borewit
Copy link
Collaborator

Borewit commented Jul 5, 2021

Related to #399.

@Borewit Borewit closed this as completed Jul 5, 2021
Borewit added a commit that referenced this issue Jul 12, 2021
Improve document stream() detection limitation.

Related: #426, #452
Borewit added a commit that referenced this issue Jul 20, 2021
Improve document stream() detection limitation.

Related: #426, #452
Borewit added a commit that referenced this issue Jul 20, 2021
Improve document stream() detection limitation.

Related: #426, #452
Borewit added a commit that referenced this issue Jul 22, 2021
Improve document stream() detection limitation.

Related: #426, #452
Borewit added a commit that referenced this issue Jul 22, 2021
Improve document stream() detection limitation.

Related: #426, #452
Borewit added a commit that referenced this issue Jul 22, 2021
Improve document stream() detection limitation.

Related: #426, #452
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants