OpenAI support - #1178

One remaining gap in the structured-output path that I think is worth a look before this lands (the schema type-case handling you added in the last commit already cleared the earlier blocker; this is the next one behind it).

Symptom: requesting structured output — either via LlmAgent's OutputSchema, or directly through GenerateContentConfig.ResponseSchema — fails against OpenAI with a 400, and the run produces no output:

openai: call failed: 400 Bad Request
Invalid schema for response_format 'adk_response':
'additionalProperties' is required to be supplied and to be false.

Minimal repro:

m, _ := openaimodel.NewModel(ctx, "gpt-4o-mini",
	&openaimodel.ClientConfig{APIKey: os.Getenv("OPENAI_API_KEY")})

req := &model.LLMRequest{
	Contents: []*genai.Content{{Role: genai.RoleUser, Parts: []*genai.Part{
		{Text: "Paris is 22C. Extract city and temperature_c."}}}},
	Config: &genai.GenerateContentConfig{
		ResponseMIMEType: "application/json",
		ResponseSchema: &genai.Schema{
			Type: genai.TypeObject,
			Properties: map[string]*genai.Schema{
				"city":          {Type: genai.TypeString},
				"temperature_c": {Type: genai.TypeInteger},
			},
			Required: []string{"city", "temperature_c"},
		},
	},
}
for _, err := range m.GenerateContent(ctx, req, false) {
	// err -> 400 ... 'additionalProperties' is required to be supplied and to be false
}

This also reproduces through a normal agent: basic_processor maps LlmAgent.OutputSchema onto Config.ResponseSchema, so any OpenAI-backed agent with an OutputSchema set hits it (with or without tools).

Root cause: the Responses API json_schema response format requires additionalProperties: false on every object node in the schema, but newJSONSchemaFormat (in model/openaimodel/request.go) doesn't add it.

How adk-python handles it: its native OpenAI Responses integration does exactly this transform in labs/openai/_openai_schema.py — enforce_strict_openai_schema() walks the schema recursively and, for each object, sets additionalProperties = False and populates required (also handling $ref/$defs/anyOf/items). Its LiteLLM path (models/lite_llm.py) applies the same rule. Python opts into OpenAI strict structured outputs, which is why it also fills required.

Possible direction (your call): mirror that helper — recursively inject additionalProperties: false on object nodes in the response-format schema (similar in spirit to the recursive lowercaseSchemaTypes you already have). If you also set strict: true to match Python's behavior, you'd want to populate required for every property too; if you keep the format non-strict, additionalProperties: false alone clears the error and optional fields keep working.

Scope / not affected:

• Function/tool calling is fine — tool parameter schemas don't hit this.
• Structured output via a raw ResponseJsonSchema that already includes "additionalProperties": false works, which is a usable workaround in the meantime.

Happy to share the exact schemas I tested if useful. Thanks again!

Found a bug in streaming + tool calling that's worth fixing before this lands (it builds on your streaming refactor).

Symptom: with an agent that has a function tool (e.g. the examples/openai weather sample), a tool-calling prompt in SSE streaming mode produces no output. It only works with non-streaming. Running it through the runner in streaming mode, the tool is never invoked — the run yields empty events with no function call.

Root cause: in the OpenAI Responses streaming API, the function name is delivered on the response.output_item.added event. The finalizing response.function_call_arguments.done event does not carry the name — it arrives empty. I confirmed this at runtime:

DONE name=""  itemID="fc_...b161e23705aef078"  args={"city":"Paris"}

emitFunctionCall builds the function call from done.Name (empty), and the shared streaming aggregator drops any completed function call whose name is empty (internal/llminternal/stream_aggregator.go — the if part.FunctionCall.Name != "" guard). So the tool call is silently discarded, the tool never runs, and streaming produces nothing.

Non-streaming is unaffected (the name comes straight from the response output items), and plain-text streaming is unaffected (no function call). The broken combination is specifically streaming + tools.

The output_item.added handling already added in this branch captures the CallID but not the Name, so the issue is still present on the current head.

Proposed fix (mirrors the existing itemToCallID mapping) in model/openaimodel/stream.go:

type streamTranslator struct {
	functionArgs map[string]*strings.Builder
	itemToCallID map[string]string
	itemToName   map[string]string // add
}

// in newStreamTranslator():
itemToName: make(map[string]string),

// in the responseOutputItemAdded case, alongside the CallID capture:
if added.Item.ID != "" && added.Item.Name != "" {
	t.itemToName[added.Item.ID] = added.Item.Name
}

// in emitFunctionCall(), before building the part:
name := done.Name
if name == "" {
	name = t.itemToName[done.ItemID]
}
delete(t.itemToName, done.ItemID)
// ...then use `Name: name` in the returned genai.FunctionCall

With this applied, streaming tool calling works end-to-end — function call → tool executes → final text streams token-by-token:

[1] fc="get_weather"
[3] fr="get_weather"
[4..] text="The" " weather" " in" " Paris" ...
[16] text="The weather in Paris is currently 22°C and sunny."

Might be worth a unit test with a fake stream where the function_call_arguments.done event omits name (and the name only appears on output_item.added), to lock this in. Happy to help if useful — thanks!