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

Return type of client.textToSpeech.convert is incorrect. #89

Open
dyerw opened this issue Oct 2, 2024 · 3 comments
Open

Return type of client.textToSpeech.convert is incorrect. #89

dyerw opened this issue Oct 2, 2024 · 3 comments

Comments

@dyerw
Copy link

dyerw commented Oct 2, 2024

Calling and awaiting the client.textToSpeech.convert infers the type stream.Readable. However logging the runtime value (at least in Node >= 18) shows the value is actually:

Node18UniversalStreamWrapper {
  readableStream: ReadableStream { locked: true, state: 'readable', supportsBYOB: true },
  reader: ReadableStreamDefaultReader {
    stream: ReadableStream { locked: true, state: 'readable', supportsBYOB: true },
    readRequests: 0,
    close: Promise { <pending> }
  },
  events: {
    data: [],
    end: [],
    error: [],
    readable: [],
    close: [],
    pause: [],
    resume: []
  },
  paused: false,
  resumeCallback: null,
  encoding: null
}

Which does not type check against the Readable class as defined by @types/node, for instance:

        /**
         * Is `true` if it is safe to call {@link read}, which means
         * the stream has not been destroyed or emitted `'error'` or `'end'`.
         * @since v11.4.0
         */
        readable: boolean;

is undefined.

@dsinghvi
Copy link
Collaborator

dsinghvi commented Oct 2, 2024

@dyerw great call -- i will take a look at this today

@johannesfritsch
Copy link

Same here

@louisjoecodes
Copy link
Collaborator

Hey @dsinghvi, could you advise on the next steps to ensure that the .convert response type is generated as a web-standard ReadableStream? Would this require a change on the Fern side of things, or is there something we can adjust in our OpenAPI definition or SDK generation process to fix it?

Any guidance would be greatly appreciated!

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

4 participants