Adding Async Function calling examples #895
Conversation
|
Check out this pull request on See visual diffs & provide feedback on Jupyter Notebooks. Powered by ReviewNB |
There was a problem hiding this comment.
Summary of Changes
Hello @Giom-V, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!
This pull request significantly enhances the Get_started_LiveAPI_tools.ipynb quickstart by introducing comprehensive examples for asynchronous function calling. It demonstrates how the model can manage tool call responses with different scheduling behaviors, such as interrupting ongoing conversations, waiting until idle, or silently processing results, providing a clearer understanding of advanced Live API capabilities.
Highlights
- Asynchronous Function Calling Examples: I've added new sections to the quickstart notebook demonstrating asynchronous function calling with the Live API. This includes examples showcasing
INTERRUPT,WHEN_IDLE, andSILENTscheduling behaviors for function responses, allowing for more flexible interaction patterns. - Custom Live API Wrapper: To facilitate the demonstration of asynchronous behaviors, I've introduced a custom
LivePython class. This class manages multi-turn asynchronous conversations and tool call processing within the notebook, providing a robust framework for the new examples. - Notebook Refinements and Updates: I've made several minor refinements across the notebook, including updating the model selection variable from
model_nametoMODEL_ID(and adding a Colab form parameter), refining a prime number helper function, and adjusting Google Search queries in existing examples. All notebook outputs have been refreshed to reflect these changes.
Using Gemini Code Assist
The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.
Invoking Gemini
You can request assistance from Gemini at any point in your pull request via creating an issue comment (i.e. comment on the pull request page) using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands.
| Feature | Command | Description |
|---|---|---|
| Code Review | /gemini review |
Performs a code review for the current pull request in its current state. |
| Pull Request Summary | /gemini summary |
Provides a summary of the current pull request in its current state. |
| Comment | @gemini-code-assist | Responds in comments when explicitly tagged, both in issue comments and review comments. |
| Help | /gemini help |
Displays a list of available commands. |
Customization
To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.
Limitations & Feedback
Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments or fill out our survey to provide feedback.
You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.
Footnotes
-
Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩
There was a problem hiding this comment.
Code Review
The code changes introduce the ability to call functions asynchronously using the Gemini Live API. The changes are well-structured and demonstrate different behaviors like BLOCKING, NON_BLOCKING with INTERRUPT, WHEN_IDLE, and SILENT modes.
My review includes several suggestions for fixing typos and grammatical errors in the markdown explanations to improve clarity. I've also pointed out a style guide violation regarding notebook execution_count values.
Most importantly, I've identified a critical issue where a blocking time.sleep() is used within an async function, which should be replaced with await asyncio.sleep() to prevent blocking the event loop.
| "## Async Function calling\n", | ||
| "\n", | ||
| "**Async Function calling** lets the model manages its function calls asynchronously and without blocking the user input.\n", | ||
| "\n", | ||
| "You can decide how the model will behave when the function call ends between saying nothing, interupting what it's doing or waiting to finish it's current task.\n", | ||
| "\n", | ||
| "The next cells are going to use a slightly updated code to use the Live API so that the session stays open for 20s and accepts multiple requests that are sent to the model every 10s. Expend the next cell if you are curious about this implementation." |
There was a problem hiding this comment.
I found a few issues in this markdown cell:
- The heading "Async Function calling" should be "Async function calling" to adhere to sentence case styling.1
- There are some typos and grammatical errors: "manages" -> "manage", "interupting" -> "interrupting", "it's" -> "its", "Expend" -> "Expand".2
Style Guide References
Footnotes
| "Let's start with the default behavior. And a mock weather function that simmulates compute time by waiting 10s.\n", | ||
| "\n", | ||
| "The behavior is what's currently happening when using function calling with the Live API, meaning that nothing can happen while the function call is being processed. It function as a FIFO pile, the function call gets in, and while it's processing everything that is being requested is queued iunstead, waiting for the function call to be finished." |
There was a problem hiding this comment.
There are a few typos and grammatical issues in this paragraph:1
- "simmulates" should be "simulates".
- "It function as a FIFO pile" should be "It functions as a FIFO queue". "Pile" is not the correct term here, and "function" is a verb.
- "queued iunstead" should be "queued instead".
- The last sentence is a bit long and could be rephrased for clarity. For example: "The function call is added to a queue, and any subsequent requests are queued behind it until it finishes processing."
Style Guide References
Footnotes
| "# Mock function, takes 10s to process\n", | ||
| "async def get_weather_vegas():\n", | ||
| " await asyncio.sleep(10)\n", | ||
| " return {'weather': \"Sunny, 42 degres\"}\n", |
There was a problem hiding this comment.
There's a typo in the string literal. "degres" should be "degrees". This typo appears in a few other places in this notebook as well (lines 1072, 1203, 1297).
return {'weather': "Sunny, 42 degrees"}
| "import time\n", | ||
| "\n", | ||
| "# Mock function, takes 10s to process\n", | ||
| "async def get_weather_vegas():\n", | ||
| " await asyncio.sleep(6)\n", |
There was a problem hiding this comment.
The import time on line 1197 is not used and can be removed.
- The comment on line 1199 says the function "takes 10s to process", but the code uses
asyncio.sleep(6). Please make them consistent for clarity.
| "When we do, we need to define the behavior of the model when it will get the result of the function call. This is managed inside of the function, or within your script that handles the funcion calls (since Automatic function calling is not available) by adding a `scheduling` value in the `FunctionResponse`..\n", | ||
| "\n", | ||
| "This time the behavior is \"**`Silent`**\", which means that the mondel won't tell you when the function call is finishedm but it might still use that knowledge later on in the conversation." |
There was a problem hiding this comment.
There are a few typos in this paragraph:1
- "funcion calls" should be "function calls".
FunctionResponse.. has an extra period.- "mondel" should be "model".
- "finishedm" should be "finished,".
Style Guide References
Footnotes
| "print(google_search.search(queries=[\"latest Brazil vs Argentina soccer match date and score\", \"Brazil Argentina soccer match history\"]))\n", | ||
| "```" | ||
| ], | ||
| "text/markdown": "``` python\nprint(google_search.search(queries=[\"latest Brazil vs Argentina soccer match date and score\", \"Brazil Argentina last match\"]))\n```", |
There was a problem hiding this comment.
It looks like the second query is not using the correct variable name. It should be Brazil Argentina last match instead of Brazil Argentina soccer match history
print(google_search.search(queries=["latest Brazil vs Argentina soccer match date and score", "Brazil Argentina last match"]))
| "The weather in Vegas\n", | ||
| " is sunny and 42 degrees.\n", |
There was a problem hiding this comment.
There's a typo in the function name. It should be degres instead of degrees
response={'weather': "Sunny, 42 degres"},
| "text/markdown": " qualifier that took place on **March 26, 2025**. Argentina won the match with a final score of **4-1**. The goals for Argentina were scored by Julian Alvarez, Enzo Fernandez, Alexis Mac Allister", | ||
| "text/plain": [ |
There was a problem hiding this comment.
There's a typo in the sentence. It should be Alexis Mac Allister instead of Alexis Mac Allister
"text/markdown": " qualifier that took place on **March 26, 2025**. Argentina won the match with a final score of **4-1**. The goals for Argentina were scored by Julian Alvarez, Enzo Fernandez, Alexis Mac Allister",
| @@ -11,7 +11,7 @@ | |||
| }, | |||
There was a problem hiding this comment.
Line #24. if text:=response.text:
Can we switch this to use the full response.candidates[0].parts... to avoid the "non-text parts" warning that's getting printed everywhere?
Reply via ReviewNB
| @@ -11,7 +11,7 @@ | |||
| }, | |||
There was a problem hiding this comment.
Would this make more sense as a stand alone notebook? It's kindof a lot to digest in a "Get Started".
Reply via ReviewNB
| @@ -11,7 +11,7 @@ | |||
| }, | |||
There was a problem hiding this comment.
And a mock
Starting a sentence with "and" doesn't seem right.
Default behavior
Maybe "Default behavior - blocking"
The behavior is what's currently happening when using function calling with the Live API,
Maybe: "The default behavior after sending a function call is for the model to wait (block) until it receives the function response"
Reply via ReviewNB
| @@ -11,7 +11,7 @@ | |||
| }, | |||
There was a problem hiding this comment.
we need to define the behavior of the model when
I'd avoid reusing the term "behavior" here since that's the parameter name. Try "For non-blocking functions the model needs to be told how to schedule each FunctionResponse."
tell us right away what we asked for
Maybe "Interrupt: stop what you're doing and handle this result"
Reply via ReviewNB
| @@ -11,7 +11,7 @@ | |||
| }, | |||
There was a problem hiding this comment.
finish what it's doing before coming back to the earlier request
Maybe "Finish what you're doing before handling this result"
This time, behavior is set as NON_BLOCKING, which means it will use async function calling.
Can we avoid repeating this on all three?
Instead of:
##blocking
##interrupt
##when_idle
##silent
Would this structure be clearer:
##blocking
##non-blocking
###interrupt
###when_idle
###silent
Reply via ReviewNB
As requested in #815