Remove Matrix and 400 error ignoring from chatCompletions

[mikhail]

No description provided.

[mikhail]

@microsoft-github-policy-service agree company="Microsoft"

[azure-sdk]

API change check

API changes are not detected in this pull request.

[deyaaeldeen]

I queued a pipeline run in https://dev.azure.com/azure-sdk/internal/_build/results?buildId=4635999&view=logs&j=43701d7e-216c-59bf-08d1-1efd0c7ac90a&t=837467d0-f383-5ba6-1b1a-21aa68346dfb and it seems that there're still a few cases that should be handled. For example:

[vitest] → 400 Unsupported Model. Model Name: 'o1-mini' Model Version '2024-09-12'. Please retry with supported model: *** (0314),gpt-35-turbo (0301),*** (1106-preview),o-mini (2024-07-18), (0613),*** (turbo-2024-04-09),gpt-35-turbo (1106),gpt-35-turbo (0125),o (2024-05-13),-32k (0613),-32k (0314), (0125-preview),***o (2024-08-06),gpt-35-turbo-16k (0613)

Azure Search Error: 403, message='Server responded with status 403. Error message: ', url='/indexes/?api-version=2024-03-01-preview'
[vitest] Server responded with status 403. Error message: ]

[mikhail]

My hunch is that these two errors should not be automatically ignored. If we expect the model to be supported and it isn't this is extremely important to become aware of. Similarly with 403 - If suddenly the live test key drops necessary permissions and all tests fire off 403 I don't want the tests to pass. Open to discussing this

[deyaaeldeen]

@mikhail Yeah I agree. There is a balance here between "are we testing the client" or "are we testing the service". I like the tests to be green as long as the client is doing its job but still I would like to get enough information in the test output to understand how the service behaves.

[mikhail]

@deyaaeldeen Agreed. I'd like to agree on some hard-defined rules on where that balance lies. If we're testing the client then let's create mock responses that include 4xx and 500 errors, and ensure that the client acts properly. If we have tests that hit the live service then it's no longer a unit/component/integration test, and shouldn't be treated as such. For example - I see zero value in, and on the contrary some danger in hitting an api that responds with Model Not Supported and then marking the test as Success, when that should be testing success of some model functionality

[deyaaeldeen]

some danger in hitting an api that responds with Model Not Supported and then marking the test as Success

I think there is a misunderstanding, the sensible thing to do here is not to use this particular model in this particular test.

[minhanh-phan]

Thank you for doing this 💯 I love the direction we're going with withDeployments. I only have some small comment, but no major concern from me!