fix: fixed gemini model handling of nullish optional fields in response schema

[pavelgj]

Zod schema like this:

schema: z.object({
  title: z.string(),
  subtitle: z.string().nulish(),
}),

and picoschema like this:

output:
  schema:
    title: string
    subtitle?: string

produce schema:

{
  "type": "object",
  "properties": {
    "title": {
      "type": "string"
    },
    "subtitle": {
      "type": [
        "string",
        "null"
      ]
    }
  },
  "required": [
    "title"
  ],
  "additionalProperties": false
}

which is not a valid schema in Gemini API request for constrained generation.

  status: 400,
  statusText: 'Bad Request',
  errorDetails: [
    {
      '@type': 'type.googleapis.com/google.rpc.BadRequest',
      fieldViolations: [
        {
          field: 'generation_config.response_schema.properties[1].value',
          description: `Invalid JSON payload received. Unknown name "type" at 'generation_config.response_schema.properties[1].value': Proto field is not repeating, cannot start list.`
        }
      ]
    }
  ]

convert

      "type": [
        "string",
        "null"
      ]

to

      "type": "string",

Checklist (if applicable):

• Tested (manually, unit tested, etc.)

[mbleigh]

This was intentional and ["string", "null"] is a valid JSON schema type. I added it as the default behavior because Gemini would frequently add null values to optional keys instead of omitting them, causing schema validation to fail when it should have succeeded.

Why is this becoming a problem?

[pavelgj]

This was intentional and ["string", "null"] is a valid JSON schema type. I added it as the default behavior because Gemini would frequently add null values to optional keys instead of omitting them, causing schema validation to fail when it should have succeeded.

Why is this becoming a problem?

Gemini response schema does not accept this as a valid schema.

  status: 400,
  statusText: 'Bad Request',
  errorDetails: [
    {
      '@type': 'type.googleapis.com/google.rpc.BadRequest',
      fieldViolations: [
        {
          field: 'generation_config.response_schema.properties[1].value',
          description: `Invalid JSON payload received. Unknown name "type" at 'generation_config.response_schema.properties[1].value': Proto field is not repeating, cannot start list.`
        }
      ]
    }
  ]

[mbleigh]

This was intentional and ["string", "null"] is a valid JSON schema type. I added it as the default behavior because Gemini would frequently add null values to optional keys instead of omitting them, causing schema validation to fail when it should have succeeded.
Why is this becoming a problem?

Gemini response schema does not accept this as a valid schema.

  status: 400,
  statusText: 'Bad Request',
  errorDetails: [
    {
      '@type': 'type.googleapis.com/google.rpc.BadRequest',
      fieldViolations: [
        {
          field: 'generation_config.response_schema.properties[1].value',
          description: `Invalid JSON payload received. Unknown name "type" at 'generation_config.response_schema.properties[1].value': Proto field is not repeating, cannot start list.`
        }
      ]
    }
  ]

Then let's fix it at the Gemini plugin level, not the Picoschema level. In the Gemini plugins, can we recursively look for array type options and replace them with the first non-"null" value? There's already a cleanSchema function because I had to do other cleanup to make Gemini happy.

[pavelgj]

This was intentional and ["string", "null"] is a valid JSON schema type. I added it as the default behavior because Gemini would frequently add null values to optional keys instead of omitting them, causing schema validation to fail when it should have succeeded.
Why is this becoming a problem?

Gemini response schema does not accept this as a valid schema.

  status: 400,
  statusText: 'Bad Request',
  errorDetails: [
    {
      '@type': 'type.googleapis.com/google.rpc.BadRequest',
      fieldViolations: [
        {
          field: 'generation_config.response_schema.properties[1].value',
          description: `Invalid JSON payload received. Unknown name "type" at 'generation_config.response_schema.properties[1].value': Proto field is not repeating, cannot start list.`
        }
      ]
    }
  ]

Then let's fix it at the Gemini plugin level, not the Picoschema level. In the Gemini plugins, can we recursively look for array type options and replace them with the first non-"null" value? There's already a cleanSchema function because I had to do other cleanup to make Gemini happy.

yeah... was just looking into cleanSchema...

interestingly, zod nullish() also produces:

     "type": [
        "string",
        "null"
      ]

we had someone on discord already run into this. I guess it makes sense to fix this at the plugin level to support both zod nullish and picoschema.