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

[core-client-rest] Implement environment checks for streaming methods #33138

Open
wants to merge 3 commits into
base: main
Choose a base branch
from

Conversation

timovv
Copy link
Member

@timovv timovv commented Feb 19, 2025

Packages impacted by this PR

  • @azure-rest/core-client
  • @typespec/ts-http-runtime

Issues associated with this PR

Describe the problem that is addressed by this PR

The result of calling asNodeStream in the browser and of calling asBrowserStream in Node is has the incorrect type. Since these methods were only ever intended to be called in their corresponding environments, this PR updates them to throw an error if they are called in the wrong environment. Also updated docs to clarify.

@timovv timovv requested review from joheredi and a team as code owners February 19, 2025 22:56
@azure-sdk
Copy link
Collaborator

API change check

API changes are not detected in this pull request.

{ ...options, allowInsecureConnection, responseAsStream: true },
httpClient,
) as Promise<HttpBrowserStreamResponse>;
if (isNodeLike) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

probably for future consideration: it would be nice if we could do feature detection of whether web stream API is available, if the support is added later

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, that would be nice. That may be slightly more involved since the stream comes directly from the HTTP client. Maybe we can eventually use Readable.toWeb, but last time I played around with that API I found it to be a bit unstable. That was over a year ago though so maybe the situation has improved a little.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In the error message could mention toWeb as something they can try? Looking at the Node docs it doesn't look like we'll be able to depend on webstreams until 22 becomes out minimum (ETA summer 2026 if I'm reading this right)

asNodeStream: () => Promise<HttpNodeStreamResponse>;
/**
* Returns the response body as a browser stream. Only available in the browser.
*/
asBrowserStream: () => Promise<HttpBrowserStreamResponse>;
Copy link
Member

@mpodwysocki mpodwysocki Feb 20, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why would we restrict this for example Deno, Bun and others by default I believe support Web Streams? I think BrowserStream makes it overall confusing and would rather just have this as asWebStream() as these are Web APIs and not necessarily browser APIs and is noted on the Node page as well

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sure, we can certainly consider this as a feature in future, and I would support doing that. But in the meantime this fix resolves the immediate issue: the type claims that asBrowserStream returns a Web stream in Node-like environments where it actually returns a Node stream.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants