weiqingy commented on code in PR #843:
URL: https://github.com/apache/flink-agents/pull/843#discussion_r3583441863
##########
integrations/chat-models/openai/src/main/java/org/apache/flink/agents/integrations/chatmodels/openai/OpenAICompletionsConnection.java:
##########
@@ -119,6 +121,11 @@ public OpenAICompletionsConnection(
this.client = builder.build();
}
+ @Override
+ protected boolean supportsNativeStructuredOutput() {
+ return true;
Review Comment:
Good catch, conceded.
One thing to add: the user can't recover from this failure.
`ChatModelAction` retries (re-failing deterministically, since a 400 for an
unsupported model isn't transient), then applies `ErrorHandlingStrategy`, so
the user gets a thrown error or, under `IGNORE`, a silently dropped record.
Nothing falls back to prompt. It slipped past the tests because
`OpenAICompletionsConnectionTest` pins `"model", "gpt-4o"`, so the native test
only passes on a capable model.
On the fix, I'd split the flag rather than move it. A `ChatModelSetup`
boolean isn't enough alone: `BaseChatModelSetup.chat()` merges per-call
`modelParams` over the setup's, so `model` is overridable per request (nothing
does that today, but the interface allows it), and the connection has its own
`defaultModel` under that. So policy (`auto`/`native`/`prompt`) on the setup,
and capability as a connection-side check against the effective model at
request-build time. Under `auto`, an incapable model falls back to prompt
instead of failing.
The stale `gpt-3.5-turbo` default looks like a separate bug anyway (the
javadoc example already uses `gpt-4o-mini`, and `OpenAIResponsesModelSetup`
defaults to `gpt-4o`), so I'll spin that out on its own.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]