This looks good to me, no concerns on my end.

This is mapped to storage.objects.get in conformance testing and is currently passing retry tests (which tells me that it's being retried). Can you fill me in on the background on why this extra logic is necessary? Is there a bug in the conformance testing? @ddelgrosso1 do you happen to know more about the background of this issue?

In looking at this code it looked like a refactor to me, not adding new functionality. Did I miss something?

I can add some clarity - this PR is for supporting retries for file#download, which utilizes file#createReadStream. Reviewing file#createReadStream's usage; it appears to be exclusively used for GET requests - which can always be retried if the configuration allows (storage.retryOptions.autoRetry).

I can add some clarity - this PR is for supporting retries for file#download, which utilizes file#createReadStream. Reviewing file#createReadStream's usage; it appears to be exclusively used for GET requests - which can always be retried if the configuration allows (storage.retryOptions.autoRetry).

From your understanding, was file.download retried before this PR? From my understanding it is.

Closed - the file#download currently supports retries and has been used validated via conformance testing:

• See storage.objects.get (and its usage):
  • https://github.com/googleapis/nodejs-storage/blob/main/conformance-test/test-data/retryInvocationMap.json#L62-L69
  • https://github.com/googleapis/nodejs-storage/blob/main/conformance-test/test-data/retryStrategyTestData.json#L313