fix: strip empty {} entries from anyOf/oneOf in strict JSON schema (#5130)

[guoyangzhen]

Summary

Fixes #5130

When a Pydantic model field is typed as Union[Literal["a", "b"], Any] (common pattern in codegen clients like Fern for forward-compatible "open enums"), model_json_schema() produces an anyOf containing a bare {} entry:

"anyOf": [
    {"enum": ["a", "b"], "type": "string"},
    {},
    {"type": "null"}
]

OpenAI's strict mode rejects schemas containing {} because it lacks a type field. This causes any FunctionTool whose signature includes a model with a Union[..., Any] field to fail at the API level.

Root Cause

_ensure_strict_json_schema recurses into anyOf/oneOf variants but doesn't strip or transform empty {} entries. Pydantic generates these for Any types in unions.

Fix

Strip empty schema objects ({}) from anyOf and oneOf arrays before recursing. {} is the JSON Schema identity element for anyOf (matches anything), so removing it is semantically neutral and makes the schema strict-mode compatible.

Changes

• livekit-agents/livekit/agents/llm/_strict.py: Filter out {} entries before processing anyOf/oneOf variants
• tests/test_tools.py: Add TestEmptySchemaStripping test class with test cases for:
  • Single model with Union[Literal, Any] field
  • Nested model containing open enum model
  • Validation that output schema contains no empty objects

Verification

from pydantic import BaseModel
from typing import Literal, Union, Any
from livekit.agents.llm._strict import to_strict_json_schema

class OpenEnum(BaseModel):
    preference: Union[Literal["a", "b"], Any, None] = None

schema = to_strict_json_schema(OpenEnum)
# Before fix: anyOf contains {} at index 1 → OpenAI rejects
# After fix: {} stripped → schema is strict-mode compatible

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[devin-ai-integration]

Devin Review found 2 potential issues.

View 3 additional findings in Devin Review.

[devin-ai-integration]

🟡 Single-element anyOf/oneOf not unwrapped after stripping empty {} entries

After stripping empty {} entries from anyOf/oneOf, if only one variant remains, the code leaves a redundant single-element wrapper (e.g., "anyOf": [{"type": "null"}] instead of just {"type": "null"}). This is confirmed reachable with Union[Any, None] (produces anyOf: [{}, {"type": "null"}] → stripped to anyOf: [{"type": "null"}]) and Union[str, Any] (produces anyOf: [{"type": "string"}, {}] → stripped to anyOf: [{"type": "string"}]). The code already handles single-element allOf by unwrapping at _strict.py:103-107, but the new stripping logic for anyOf/oneOf doesn't include analogous unwrapping. Additionally, if all variants are {} (extremely unlikely), the result would be anyOf: [] which is invalid JSON Schema.

(Refers to lines 84-88)

Prompt for agents

In livekit-agents/livekit/agents/llm/_strict.py, after stripping empty {} entries from anyOf (lines 84-88) and oneOf (lines 94-98), add handling for the case where the filtered list has 0 or 1 elements, similar to the existing allOf handling at lines 103-107.

For anyOf (around line 84):
1. After filtering (any_of = [v for v in any_of if v != {}]), check len(any_of).
2. If len(any_of) == 0: remove the anyOf key from json_schema entirely (json_schema.pop("anyOf", None)).
3. If len(any_of) == 1: unwrap the single element by updating json_schema with the processed single variant and removing the anyOf key, similar to the allOf single-element pattern at lines 103-107.
4. Otherwise (len >= 2): proceed with the existing logic.

Apply the same pattern to oneOf (around line 94).

---

Was this helpful? React with 👍 or 👎 to provide feedback.

[devin-ai-integration]

🟡 Unused import typing in test file violates CONTRIBUTING.md lint rule

import typing on line 3 is unused — typing is never referenced by name in the file (all needed symbols are imported via from typing import Any, Literal, Union). Running ruff check confirms the F401 violation. CONTRIBUTING.md mandates running ruff check --fix before committing, which would remove this import.

Suggested change

import typing

---

Was this helpful? React with 👍 or 👎 to provide feedback.

[theomonnom]

Hey, lgtm, can you fix the ruff CI?

[theomonnom]

Continued here: #5137