58333b2705
Same async-tool routing approach as #4441: detect async-tool messages in the LLM context, deliver the final result via the formal tool-result channel. Caveat: as of this writing, Inworld Realtime doesn't appear to handle the resulting delayed tool result reliably, so the routing is best-effort and the service emits a one-time warning when async-tool messages are seen. Streamed intermediate results remain unsupported. Also adds function calling to the realtime-inworld.py example, and softens the Inworld mention in the #4447 changelog now that the exclusion is being closed.
1.1 KiB
1.1 KiB
- Extended the
cancel_on_interruption=Falseregression fix toGrokRealtimeLLMService,AzureRealtimeLLMService, andUltravoxRealtimeLLMService. Grok and Azure use the same approach as in #4441 (each service detects async-tool messages in the LLM context and routes the final result to its formal tool-result channel; Azure inherits transitively fromOpenAIRealtimeLLMService). Ultravox needed a different approach because its API freezes the conversation betweenclient_tool_invocationand the matchingclient_tool_result— for async-registered functions it now ships a placeholderclient_tool_resultimmediately when the function is invoked (to unfreeze the conversation), then injects the real result as user-side text once the tool finishes. Streamed intermediate results (FunctionCallResultProperties(is_final=False)) are still not supported on any of these realtime services.GeminiLiveLLMServiceandInworldRealtimeLLMServiceare excluded for now: Gemini Live's async-tool path needs deeper investigation, and Inworld tool calling needs to be sorted out first.