Invalid schema when using "anyOf" in the response schema. Need help with discriminator key

API
, ,
1

I am working with Structured outputs. I have set strict to true. Here is the response schema I am providing when calling the API:

{
  "$defs": {
    "Question": {
      "discriminator": {
        "propertyName": "QuestionType"
      },
      "anyOf": [
        {
          "type": "object",
          "properties": {
            "QuestionType": {
              "type": "string",
              "enum": ["MC"]
            },
            "QuestionText": {
              "type": "string"
            },
            "Choices": {
              "type": "array",
              "items": {
                "type": "string"
              }
            }
          },
          "required": ["QuestionType", "QuestionText", "Choices"]
        },
        {
          "type": "object",
          "properties": {
            "QuestionType": {
              "type": "string",
              "enum": ["TE"]
            },
            "QuestionText": {
              "type": "string"
            }
          },
          "required": ["QuestionType", "QuestionText"]
        }
      ]
    }
  },
  "type": "object",
  "properties": {
    "questions": {
      "type": "array",
      "items": {
        "$ref": "#/$defs/Question"
      }
    }
  },
  "required": ["questions"]
}

But I still get the following error

400 Invalid schema: Objects provided via 'anyOf' must not share identical first keys. Consider adding a discriminator key or rearranging the properties to ensure the first key is unique.

Am I adding the discriminator key properly and at the right place?

2

As a workaround for now, I changed the order of keys so that no object inside the anyOf array has the same first key.
But that feels like an unnecessary change to do if I am assuring that QuestionType has a different schema in each object and the discriminator key definition works as expected, which it is not. Probably because I am not defining it correctly or at the wrong location. Still looking for an answer on that.

3

Strange, but the same schema seems to work now without any errors. I guess some kind of update might have been pushed for the response schema validation.