RuntimeWarning: coroutine 'LLMService._run_function_call' was never awaited when a function call is cancelled by user-turn-start interruption race (distinct from #3588)

[elliottventures]

pipecat version

1.0.0 (from pypi)

Python version

3.14.4

Operating System

macOS (Apple Silicon)

Issue description

A RuntimeWarning fires — and more importantly the Gemini Live session stalls for ~10 seconds — when a function call dispatched by GeminiLiveLLMService is cancelled by an interruption broadcast originating from TranscriptionUserTurnStartStrategy.

This is distinct from #3588:

• Different coroutine. RuntimeWarning: coroutine 'LLMService._run_function_call.<locals>.timeout_handler' was never awaited when function call triggers pipeline end #3588 reports _run_function_call.<locals>.timeout_handler being unawaited; this report is the outer _run_function_call coroutine itself being unawaited.
• Different trigger. RuntimeWarning: coroutine 'LLMService._run_function_call.<locals>.timeout_handler' was never awaited when function call triggers pipeline end #3588 is triggered by a function handler pushing EndTaskFrame / EndFrame. This one is triggered by the normal turn-interruption race: when input transcription arrives and LLMUserAggregator broadcasts an interruption frame within the same millisecond the model emits a tool call.

#3588's fix (a finally: cancel_task(timeout_task) block) targets the inner timeout handler; it does not address this outer-coroutine leak on interruption cancellation.

The warning is a symptom. The substantive problem is that Gemini Live never receives the function-call result, and its session sits idle producing zero completion tokens for ~10 seconds until the next user utterance triggers a server-side VAD interruption and unsticks it. For an agent that performs many tool calls in a conversation, this is a meaningful UX regression, not cosmetic.

Reproduction steps

1. Use examples/realtime/realtime-gemini-live-function-calling.py with GeminiLiveLLMService (not Vertex), Daily transport in direct mode (-t daily -d).
2. Speak a question that fires a registered function (e.g. "What's the weather in Tokyo?"). The very first turn of a fresh session reliably triggers the race; later turns hit it occasionally.
3. Observe:
   • _handle_msg_input_transcription logs the user text
   • _on_user_turn_started fires broadcast_interruption
   • _run_function_call starts
   • _cancel_function_call fires within ~1 ms
   • RuntimeWarning: coroutine 'LLMService._run_function_call' was never awaited is emitted
   • The next 10+ seconds show TTFB: 10.421s, prompt tokens: 0, completion tokens: 0 — Gemini produces nothing because it's still waiting for the cancelled tool result
   • Only the next user utterance's Gemini-VAD interruption signal unblocks the session

Expected behavior

The function call should either:

• Not be cancelled by a same-turn interruption broadcast (the tool was requested by the current turn; interrupting the current turn shouldn't kill it), or
• If cancellation is required, its outer coroutine should be awaited/cancelled cleanly and Gemini should be notified so it doesn't stall waiting for an undelivered result.

No RuntimeWarning in either case.

Actual behavior

• RuntimeWarning: coroutine 'LLMService._run_function_call' was never awaited
• Session stalls for ~10 seconds (0 completion tokens, TTFB: 10.421s)
• Stalled state only clears when the next user utterance triggers a fresh VAD interruption

Logs (trimmed to the critical window)

18:15:28.682 [Transcription:user] [Oh, what's the weather in Tokyo?]
18:15:28.683 _on_user_turn_started (TranscriptionUserTurnStartStrategy#0)
18:15:28.683 broadcast_interruption
18:15:28.687 _on_user_turn_stopped (TurnAnalyzerUserTurnStopStrategy#0)
18:15:28.689 Cancelling function call [get_current_weather:fc_13054767619604724024]...
18:15:28.690 Function call [get_current_weather:...] has been cancelled
/path/to/python3.14/asyncio/events.py:94: RuntimeWarning:
  coroutine 'LLMService._run_function_call' was never awaited
18:15:28.696 FunctionCallsStartedFrame: ['get_current_weather:...']
18:15:28.697 FunctionCallCancelFrame: [get_current_weather:...]
18:15:39.110 Gemini VAD: interrupted signal received
18:15:39.111 broadcast_interruption (GeminiLiveLLMService#0)
18:15:39.111 TTFB: 10.421s
18:15:39.112 prompt tokens: 0, completion tokens: 0
18:15:41.925 [Transcription:user] [Recommend a restaurant in Paris.]

Potential direction (not a fix, just a hypothesis)

LLMUserAggregator broadcasts interruption on _on_user_turn_started without regard for whether the current turn's LLM response is emitting a tool call. An interruption that cancels a just-fired tool call from the same turn is arguably wrong — the tool was requested by this turn, not a stale prior one.

Options worth considering:

1. Suppress interruption-driven cancellation for function calls emitted within the same turn window as the interruption.
2. Still cancel, but send a synthetic error result back to Gemini so it doesn't stall waiting.
3. Ensure the outer _run_function_call coroutine is properly awaited on the cancellation path so the warning at minimum goes away.

[markbackman]

This is not a known issue. Can you try running this example if you aren't already?
https://github.com/pipecat-ai/pipecat/blob/main/examples/realtime/realtime-gemini-live-function-calling.py

I'm running on python 3.13.7 without an issue. I don't have access to 3.14.4 on my machine (uv not serving it yet...).

[elliottventures]

Good call asking us to isolate. On our environment (Python 3.14.4, Pipecat 1.0.0, macOS arm64, GeminiLiveLLMService against AI Studio, Daily direct mode) I ran the canonical example and added the three edits I originally had applied back one at a time. Results:

Test	Model	VAD config	System instruction	Tool calls	Cancellations	RuntimeWarning
Pristine	gemini-2.5-flash-native-audio-preview-12-2025 (default)	None (default)	canonical	2	0	0
+ Model only	gemini-3.1-flash-live-preview	None (default)	canonical	5	0	0
+ Model + VAD	gemini-3.1-flash-live-preview	GeminiVADParams(start=LOW, end=LOW, prefix=300, silence=1200)	canonical	4	4	1

System instruction was the canonical example's in all three tests, so it's not that.

The trigger is the GeminiVADParams overrides, not the model. Python 3.14.4 looks like a necessary ingredient too (since you can't reproduce on 3.13.7), but on 3.14.4 the model alone is fine; it's adding the VAD tuning that causes tool calls to get cancelled within 1–2 ms of being dispatched. Same symptom pattern as the original report — the FunctionCallResultFrame usually still reaches Gemini (cancel-initiated-but-result-delivered), but intermittently the cancel wins fully and we get both the RuntimeWarning: coroutine 'LLMService._run_function_call' was never awaited and the ~10 second stall waiting on a result that never arrives. In my Test C run, 3 of 4 tool calls were cancel-but-delivered, 1 of 4 was fully cancelled + RuntimeWarning.

Minimal reproducer

Apply to examples/realtime/realtime-gemini-live-function-calling.py:

-from pipecat.services.google.gemini_live.llm import GeminiLiveLLMService
+from google.genai.types import EndSensitivity, StartSensitivity
+
+from pipecat.services.google.gemini_live.llm import GeminiLiveLLMService, GeminiVADParams

     llm = GeminiLiveLLMService(
         api_key=os.getenv("GOOGLE_API_KEY"),
         settings=GeminiLiveLLMService.Settings(
+            model="models/gemini-3.1-flash-live-preview",
             system_instruction=system_instruction,
+            vad=GeminiVADParams(
+                start_sensitivity=StartSensitivity.START_SENSITIVITY_LOW,
+                end_sensitivity=EndSensitivity.END_SENSITIVITY_LOW,
+                prefix_padding_ms=300,
+                silence_duration_ms=1200,
+            ),
         ),
         tools=tools,
     )

Run with -t daily -d, connect from a browser, ask any tool-firing question. 4 of 4 tool calls raced on my run.

Hypothesis

The tuned VAD (lower start/end sensitivity + 1200 ms silence) makes Gemini's server-side VAD less eager to commit turn boundaries, which shifts when Pipecat receives the [Transcription:user] frame relative to Gemini's tool-call emission. With pristine VAD defaults the transcription arrives well before the tool call; with the tuned values the two events arrive within ~1 ms of each other, and LLMUserAggregator.broadcast_interruption on _on_user_turn_started ends up racing the tool dispatch. Handwave — you'll know better — but the narrowing points cleanly at a timing interaction between the VAD tuning and the transcription-based turn-start interruption.

Happy to run additional narrowing if it would help (toggling the four GeminiVADParams fields one at a time to find which specific knob tips it over). Or if the fix direction is "don't cancel a function call emitted by the same turn that triggered the interruption," happy to be the reference repro.