Producing this many bytes from a Process[F, ByteVector]
should require
at least one F
effect.
Producing this many bytes from a Process[F, ByteVector]
should require
at least one F
effect.
The scenarios this is intended to handle involve prepending a small wrapper around a stream, like "[\n" when outputting JSON data in an array, and thus 100 bytes seemed large enough to contain these cases and small enough as to not force more than is needed.
This exists because of how http4s handles errors from Process
responses.
If an error is produced by a Process
while streaming the connection is
severed, but the headers and status code have already been emitted to the
wire so it isn't possible to emit a useful error message or status. In an
attempt to handle many common scenarios where the first effect in the stream
is the most likely to error (i.e. opening a file, or other resource to stream
from) we'd like to step the stream until we've reached the first F
effect
so that we can see if it succeeds before continuing with the rest of the
stream, providing a chance to respond with an error in the failure case.
We cannot just Process.unemit
the Process
as there may be non-F
Await
steps encountered before an actual F
effect (from many of the combinators
in process1
and the like).
This leads us to the current workaround which is to define this threshold
which should be, ideally, just large enough to require the first F
to
produce the bytes, but not more. We then consume the byte stream until it
ends or we've consumed this many bytes. Finally we have a chance to inspect
the F
and see if anything failed before handing the rest of the process
to http4s to continue streaming to the client as normal.