fix(azure/audio): use model param for deployments

[deyaaeldeen]

Issue: #1289

The buildRequest method in AzureOpenAI is overridden to construct the Azure request URL using the deployment name, which can be set either on the client or in the request body. However, for audio operations, the request body is converted into a stream before buildRequest is called, making the deployment information inaccessible.

This PR resolves the issue by intercepting calls to the underlying create methods and capturing the deployment value before the request body is converted into a stream.

[RobertCraigie]

Ah I see why this is difficult, I think instead we could retain the model information by passing it down as a separate request option. e.g. adding a _metadata?: Record<string, unknown> property, then instead of having to override the resource classes for the azure client we could just specify that in the main resource class, e.g.

    return this._client.post('/audio/transcriptions', Core.multipartFormRequestOptions({ body, ...options, _metadata: { model: body.model } }));

I think this is cleaner and I suspect your implementation won't work for retries fwiw

[deyaaeldeen]

@RobertCraigie good point, addressed in 6a39d7e. I was initially hesitant to edit code under resources because I think it is auto-generated.

Speaking of retries, I think we're in a tricky situation there when the user passes in a stream and it gets exhausted in the initial request. When it is time to retry to the request (let's say because of a 429), the request gets stuck and nothing is sent to the server because the stream is already exhausted. To get a round this, we need to require the input to be a stream factory that can reproduce the stream between retries. Is there any chance we can address this in the upcoming v5?

[RobertCraigie]

I was initially hesitant to edit code under resources because I think it is auto-generated.

Ah yeah that used to be a concern but now we can make arbitrary changes to the generated code :)

Speaking of retries, I think we're in a tricky situation there when the user passes in a stream and it gets exhausted in the initial request. When it is time to retry to the request (let's say because of a 429), the request gets stuck and nothing is sent to the server because the stream is already exhausted. To get a round this, we need to require the input to be a stream factory that can reproduce the stream between retries. Is there any chance we can address this in the upcoming v5?

Ah..... thanks for the report, I don't think we would want to require a stream that can be retried but we definitely need to improve the DX here and provide some solution, we'll investigate, thanks!

[RobertCraigie]

Looks great!

One last question, is this a breaking change? I think so?

[deyaaeldeen]

we'll investigate, thanks!

Awesome, thanks!

is this a breaking change?

It shouldn't break existing working code that I know of, the order of places to get the deployment value from didn't change.