Skip to content

fix(gemini): infer missing type:"object" for schema nodes with properties#1941

Open
Blue-B wants to merge 2 commits intorouter-for-me:mainfrom
Blue-B:fix/gemini-infer-missing-object-type
Open

fix(gemini): infer missing type:"object" for schema nodes with properties#1941
Blue-B wants to merge 2 commits intorouter-for-me:mainfrom
Blue-B:fix/gemini-infer-missing-object-type

Conversation

@Blue-B
Copy link

@Blue-B Blue-B commented Mar 7, 2026

Gemini API rejects tool schemas where a node has properties but no type field

Added inferMissingObjectType to the schema cleanup pipeline. It walks the schema tree and sets type: "object" on any node that has properties without an explicit type.

Fixes tool_use failures when MCP tools or Droid CLI send schemas without explicit object types.

@gemini-code-assist
Copy link
Contributor

Summary of Changes

Hello, 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 addresses a critical compatibility issue with the Gemini API by enhancing the schema cleanup process. It introduces a mechanism to automatically infer and set the type of schema nodes to object when they contain properties but omit an explicit type declaration. This ensures that tool schemas, particularly from systems like MCP and Droid CLI, are correctly interpreted and accepted by the Gemini API, preventing tool-use failures.

Highlights

  • Schema Validation Fix: Introduced a new function, inferMissingObjectType, to automatically add type: "object" to schema nodes that define properties but lack an explicit type field.
  • API Compatibility: This change resolves issues where the Gemini API would reject tool schemas that were missing explicit object type declarations, ensuring broader compatibility for tools like MCP and Droid CLI.

🧠 New Feature in Public Preview: You can now enable Memory to help Gemini Code Assist learn from your team's feedback. This makes future code reviews more consistent and personalized to your project's style. Click here to enable Memory in your admin console.

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.

Copy link
Contributor

@gemini-code-assist gemini-code-assist bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code Review

This pull request aims to fix an issue with Gemini tool schemas by ensuring that any schema node with a properties field also has type: "object". The implementation introduces a new function, inferMissingObjectType, into the schema cleanup pipeline. However, there's a critical issue in the new function where a conditional check always evaluates to true, making the function a no-op and preventing the fix from working. My review includes a comment to address this.

Comment on lines +507 to +509
if isPropertyDefinition(p) {
continue
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

critical

The condition isPropertyDefinition(p) will always evaluate to true for any path p returned by findPaths(jsonStr, "properties"). The findPaths function returns paths that end with the properties key (e.g., a.b.properties), and isPropertyDefinition checks for exactly that pattern. As a result, the continue statement is always executed, which makes this new function a no-op and prevents it from fixing the issue described in the pull request. This check appears to be erroneous and should be removed to allow the function to work as intended.

Add inferMissingObjectType to the Gemini schema cleanup pipeline.
When a schema node has "properties" but no "type" field, Gemini API
rejects it. This fix infers type:"object" for such nodes, preventing
tool_use failures with Gemini models.
@Blue-B Blue-B force-pushed the fix/gemini-infer-missing-object-type branch from e433d91 to fe7b1ee Compare March 7, 2026 16:31
@Blue-B
Copy link
Author

Blue-B commented Mar 7, 2026

Fixed — moved the isPropertyDefinition check to use parentPath instead of p, matching the pattern used elsewhere in this file. Thanks for catching this.

Copy link
Collaborator

@luispater luispater left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Summary:
This moves the Gemini schema cleanup in the right direction, but there is still a correctness gap for valid schemas that contain a literal property named properties.

Key findings:

  • Blocking: the new inference still skips schema nodes under a field literally named properties. Walk() builds paths like properties.properties.properties, and isPropertyDefinition() still classifies those by suffix, so the target node is treated as a properties container instead of a field definition. In that case we still fail to add type: "object", so the original Gemini rejection remains possible.
  • Non-blocking: please add regression coverage for both (1) a normal node with properties but no type, and (2) the edge case where a field is literally named properties.

Test plan:

  • Reviewed the diff and the schema traversal helpers.
  • Verified the path-classification behavior with a minimal reproduction based on the current Walk / isPropertyDefinition logic.

…gObjectType

Replace isPropertyDefinition with isSchemaPropertiesKeyword that correctly
distinguishes JSON Schema 'properties' keywords from fields named 'properties'
by walking the path and tracking schema-vs-field depth.

Add regression tests for both normal and edge-case schemas.
@Blue-B
Copy link
Author

Blue-B commented Mar 9, 2026

Addressed both blocking and non-blocking feedback — pushed a fix:

  1. Edge case fix: Replaced isPropertyDefinition with isSchemaPropertiesKeyword in inferMissingObjectType. The new function walks path segments tracking schema-vs-field depth, so a field literally named "properties" is correctly handled.

  2. Regression tests added (5 cases):

    • Normal node with properties but no type → adds type:"object"
    • Existing type not overwritten
    • Nested schema missing type
    • Field literally named "properties" (string field) → not modified
    • Field named "properties" that itself has sub-properties → gets type:"object"

Please take another look when you get a chance.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants