azure-sdk-for-js: [recorder] binary response encoded in 'hex' do not work well
When the response body is binary data, our recoder will store the data in hex.
When consuming the data in playback mode, we can’t infer the encoding: response.readableStreamBody?.readableEncoding = null.
If I set the encoding manually with response.readableStreamBody?.setEncoding("hex"); The data get decoded correctly. Yet the length of data is not right. As in live mode, we are expecting binary data. With stream.read(size), we mean to the size of bytes(8 bits). But for ‘hex’ data, each byte/char only contain 4 meaningful bits.
Ran into this with the tests for quick query and change feed. https://github.com/Azure/azure-sdk-for-js/blob/66799d5b0238c6d3870dca2173f99aea9145578a/sdk/storage/storage-blob/test/node/blobclient.spec.ts#L351
About this issue
- Original URL
- State: closed
- Created 4 years ago
- Comments: 17 (16 by maintainers)
@ljian3377 That’s interesting.
I believe this is what you are referring to. https://github.com/Azure/azure-sdk-for-js/blob/317b9d825b4bc84de17529328340014124d6c7dd/sdk/storage/storage-blob-changefeed/recordings/node/blobchangefeedclient/recording_bypage.js#L382
I think I know what went wrong… The status code here is “206” in the reply, my previous fix only allows filtering the “200” status code(Intention behind that was to not do greedy replacements).
The API should support both browser and Node in the end. We are still working on it. The recorder utilities need to guarantee we get the same data in live and playback mode. In live mode, we are expecting binary data - 8 bits for a byte. The length matters.
I couldn’t find a way to get the encoding of the ReadableStream so not able to workaround accordingly.
@HarshaNalluru Yes, the subscription needs to register the quick query feature and probably it now only works in central Canada and France in production. I will ping you with the account info I am using.