fix(tools): preserve integer precision in tool calls (#3592)

[sarojrout]

Please ensure you have read the contribution guide before creating a pull request.

Link to Issue or Description of Change

1. Link to an existing issue (if applicable):

• Closes: Big integer precision loss in tool calling #3592
• Related: #issue_number

2. Or, if no issue exists, describe the change:

If applicable, please follow the issue templates to provide as much detail as
possible.

Problem:
Gemini function calls serialize integer parameters as JSON numbers. When those exceed double precision, they arrive in ADK as floats (e.g. 1e16) and Python converts them to float, so user tools lose precision (10000000000000001 + 123456789 → 10000000123456788).

Solution:
During schema generation (Gemini variant), rewrite integer parameters/returns as strings with regex ^-?\d+$ so the model sends them as exact strings.
When the tool executes, FunctionTool now coerces such strings/Decimals/floats back to precise Python int values before invoking the code.
Added unit tests covering both the schema change and the runtime conversion.

Testing Plan

Please describe the tests that you ran to verify your changes. This is required
for all PRs that are not small documentation or typo fixes.

Unit Tests:

• I have added or updated unit tests for my change.
• All unit tests pass locally.

pytest tests/unittests/tools/test_function_tool.py::test_run_async_with_large_integer_strings tests/unittests/tools/test_from_function_with_options.py::test_from_function_with_options_int_parameter_gemini -q

Manual End-to-End (E2E) Tests:

Please provide instructions on how to manually test your changes, including any
necessary setup or configuration. Please provide logs or screenshots to help
reviewers better understand the fix.

Checklist

• I have read the CONTRIBUTING.md document.
• I have performed a self-review of my own code.
• I have commented my code, particularly in hard-to-understand areas.
• I have added tests that prove my fix is effective or that my feature works.
• New and existing unit tests pass locally with my changes.
• I have manually tested my changes end-to-end.
• Any dependent changes have been merged and published in downstream modules.

Additional context

Created a simple add(a: int, b: int) tool via FunctionTool.
Invoked it with Gemini-style strings ("10000000000000001" and "123456789") through ADK; observed exact result 10000000123456790.

[gemini-code-assist]

Summary of Changes

Hello @sarojrout, I'm Gemini Code Assist¹! 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 resolves a significant data integrity problem within the ADK's function calling mechanism, specifically for the Gemini API. By strategically altering how large integers are represented in the generated schema and implementing a robust runtime conversion logic, the system now guarantees that integer values maintain their full precision, eliminating unintended floating-point approximations during tool execution.

Highlights

• Precision Loss Fix: Addresses a critical issue where large integer parameters in Gemini function calls would lose precision due to serialization as JSON numbers and subsequent conversion to floats in Python.
• Schema Generation Update: Modifies the schema generation process for the Gemini variant to represent integer parameters and return values as strings, enforced by a regular expression (^-?\d+$), ensuring they are transmitted as exact strings.
• Runtime Type Coercion: Enhances the FunctionTool to intelligently coerce incoming string, Decimal, or float values back into precise Python int types before invoking the user's function, preventing data loss.
• Comprehensive Testing: Includes new unit tests to validate both the updated schema generation for integer parameters and the correct runtime conversion of large integer strings, ensuring the fix is robust.

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 by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

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 pull request 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. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

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

1. 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. ↩

[gemini-code-assist]

Code Review

This pull request effectively addresses a critical precision loss issue with large integers in Gemini function calls. The approach of converting integers to strings in the schema for the Gemini variant and then safely converting them back to Python ints at runtime is well-implemented. The changes are robust, considering various numeric types like float and Decimal during the conversion process. The inclusion of unit tests for both schema generation and runtime conversion is excellent. I have a minor suggestion to improve consistency between the schema generation and parsing logic.

[gemini-code-assist]

The regex pattern for integer strings is inconsistent with the one used for parsing in function_tool.py. Here, it is r'^-?\d+$', while in function_tool.py it is r'^[-+]?\d+$', which also allows a leading +. While the Gemini model might not generate a leading +, it's best practice to keep the schema pattern and the parser logic consistent. This makes the system more robust. Please consider updating the pattern to allow for an optional positive sign.

Suggested change

	_INTEGER_STRING_PATTERN = r'^-?\d+$'
	_INTEGER_STRING_PATTERN = r'^[-+]?\d+$'

[gemini-code-assist]

To align with the suggested change to the integer string pattern in _function_parameter_parse_util.py, this test assertion should be updated to reflect the new, more robust pattern.

Suggested change

	assert param_schema.pattern == '^-?\\d+$'
	assert param_schema.pattern == '^[-+]?\d+$'

[xuanyang15]

Thanks for creating this PR! After talking with team, this might not be the best way to resolve this issue. I will comment in the issue for the alternatives.

[sarojrout]

I will work on the review comments which you had given earlier and those are valid points. for example:
LLM → Tool: Integer strings are converted to Python int (already fixed)
I will add testcase for
Tool → LLM: Large integers (>= 2**53) are converted to strings before JSON serialization
Will fix the regex pattern
will fix the conversion logic for nested structures
anything else @xuanyang15 ?

[xuanyang15]

@sarojrout Sorry, as I mentioned in #3594 (comment), this might not be the best way to resolve the issue, since it affects all the users of ADK. I'm reaching out the upstream team for a more elegant fix. See #3592 (comment), @yyyu-google is working on it.