fix(voice): Fixed response types on file downloads #864
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
Fixed the response type expectations when downloading recordings and transcriptions.
This also adds a
downloadTranscription()
method to voice to make it easier to download transcriptions.Motivation and Context
By default, the
server-client
clients expect a response in JSON. This is fine for API calls as we almost always expect JSON responses, but voice recordings and transcriptions should be treated as buffers instead. This change lets recordings be downloaded usingres.buffer()
and transcripts be downloaded usingres.text()
decoding.Note that the
FileClient
by itself could have worked directly by overriding the config option as "text" since text just act like a generic buffer, but adding astream
response type is semantically more clear.Testing Details
Manual testing
Example Output or Screenshots (if appropriate)
Types of changes
Checklist