Repository navigation
Propagate 'response' event through file.createReadStream() #606
Copy link
Copy link
Closed
Description
Activity
Interesting use case. I don't see why we couldn't support this. I'm all for exposing this functionality if it helps our users :) @stephenplusplus what do you say?
@robertdimarco I'm going to make an executive decision here and say "why not!". Could you create a PR for this change with a unit test or two and assign me to review when you're ready? Thanks!
@ryanseys Sure thing, I'll follow-up with that shortly.
👍
Thanks, @robertdimarco!
- added a commit that references this issue
on Jan 10, 2023 - added a commit that references this issue
on Sep 13, 2023 12 remaining items
- added a commit that references this issue
on Feb 3, 2026 - added a commit that references this issue
on Feb 5, 2026 - added a commit that references this issue
on Feb 17, 2026 - added a commit that references this issue
on Feb 23, 2026 - added a commit that references this issue
on Feb 24, 2026 - added a commit that references this issue
on Mar 17, 2026 - added a commit that references this issue
on Mar 18, 2026
Metadata
Metadata
Assignees
Labels
No labels
_Background_:
We run a proxy service that serves a large number of files of varying size to downstream clients. In cases where we encounter an error serving the requested file (such as 404s) we intercept the error to the downstream client and pass through a custom error and template. See #522 for an oversimplified version.
_Request_:
The previous request to remove the required call to
file.getMetadata()before invokingfile.createReadStream()has been a big help in reducing mean latency since it removed a roundtrip for each download request. Our next challenge has been intercepting errors (namely those 404s) in a way that continues to let us simply pipe the result to the downstream client (and not buffer the download file until completion), and send the appropriate status code + headers.Currently, in the case of a 404, the stream returned from
file.createReadStream()will first emit adataevent (an XML response containing an error) and then emits anerrorevent (the formatted error object). Ideally, we could inspect the response headers before deciding whether or not to stream the result from GCS down to the client, and currently we have to buffer some number ofdataevent payloads until we're sure we haven't encountered a GCS error._Details_:
The Node
http.ClientRequestclass specifies aresponseevent that fires once and exposes (amongst other things) the HTTP response headers. If we could subscribe to that event, it would allow us to inspect the response from GCS, send the appropriate status code and headers to our downstream client, prior to piping any data.Don't hesitate to let me know if you have any thoughts or questions, and thanks for all of your hard work on this library!