fix(tools): support regional Discovery Engine endpoints

[kaligautier]

Link to Issue or Description of Change

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

• Closes: DiscoveryEngineSearchTool: 400 error with regional (non-global) data stores #4697
• Related: N/A

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

Problem:
DiscoveryEngineSearchTool was always initialized with the default global
endpoint. This caused 400 errors for non-global data stores/search engines
(eu, us, europe-west1, etc.).

Additionally, location extraction from the resource id was too permissive.
Malformed values could be used to construct an unsafe api_endpoint.

Solution:

• Add endpoint resolution based on location (global keeps default endpoint,
  regional locations use <location>-discoveryengine.googleapis.com).
• Add optional location input to DiscoveryEngineSearchTool so callers can
  explicitly set global, us, eu, etc.
• Keep location optional: when not provided, infer from data_store_id /
  search_engine_id, then fallback to global.
• Add consistency check: if location is provided and resource id contains a
  location, both must match.
• Harden validation to allow only valid location characters
  ([a-z0-9-]) for both explicit and inferred locations.
• Reject invalid/malformed resource locations with ValueError.
• Preserve quota_project_id in ClientOptions.
• Extend unit tests for all above behaviors, including invalid input cases.

Testing Plan

Unit Tests:

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

Summary of passed pytest results:

.venv/bin/pytest tests/unittests/tools/test_discovery_engine_search_tool.py -q
..................                                                       [100%]
18 passed in 1.75s

Manual End-to-End (E2E) Tests:

Manual local verification was run by instantiating the tool with representative
resource IDs and checking the endpoint passed to SearchServiceClient:

location=global endpoint=discoveryengine.googleapis.com (default)
location=us endpoint=us-discoveryengine.googleapis.com
location=eu endpoint=eu-discoveryengine.googleapis.com

Invalid input verification (local):

• Explicit location="attacker.com#" raises ValueError.
• Resource id containing locations/attacker.com# raises ValueError.

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

This PR now contains a single squashed commit.

[google-cla]

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.

[gemini-code-assist]

Summary of Changes

Hello, 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 enhances the DiscoveryEngineSearchTool to correctly handle regional Google Cloud Discovery Engine endpoints. Previously, the tool exclusively used the global endpoint, leading to errors when interacting with resources in specific geographical regions. The changes introduce dynamic endpoint resolution based on resource IDs and ensure proper configuration of the SearchServiceClient, thereby improving the tool's robustness and usability across different Google Cloud regions.

Highlights

• Regional Endpoint Support: Implemented logic to dynamically determine and use regional Discovery Engine API endpoints based on the provided data_store_id or search_engine_id.
• Error Resolution: Fixed an issue where DiscoveryEngineSearchTool would produce 400 errors for non-global locations due to always initializing SearchServiceClient with the default global endpoint.
• Quota Project ID Preservation: Ensured that the quota_project_id is correctly preserved and passed to ClientOptions when regional endpoints are used.
• Comprehensive Testing: Added new unit tests covering global, EU, US, and specific regional locations (e.g., europe-west1), including scenarios with quota_project_id.

🧠 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.

Changelog

• src/google/adk/tools/discovery_engine_search_tool.py
  • Imported the re module for regular expression operations.
  • Defined constants _DEFAULT_ENDPOINT, _GLOBAL_LOCATION, and _LOCATION_PATTERN for endpoint and location parsing.
  • Introduced a new helper function _build_client_options to construct client_options.ClientOptions dynamically, setting the api_endpoint based on the extracted location and including quota_project_id if available.
  • Modified the init method of DiscoveryEngineSearchTool to utilize _build_client_options for creating the SearchServiceClient's client_options.
• tests/unittests/tools/test_discovery_engine_search_tool.py
  • Added new parameterized unit tests to verify that the DiscoveryEngineSearchTool correctly initializes SearchServiceClient with regional API endpoints for various locations (e.g., eu, us, europe-west1).
  • Included a unit test to confirm that the default global endpoint is maintained when the resource ID specifies a global location.
  • Added a unit test to ensure that both a regional API endpoint and the quota_project_id are correctly applied simultaneously when initializing the client.

Activity

• Linked to issue DiscoveryEngineSearchTool: 400 error with regional (non-global) data stores #4697.
• Provided a detailed description of the problem and the proposed solution.
• Outlined a testing plan including unit tests and manual end-to-end verification.
• Confirmed that all unit tests were added/updated and passed locally, providing pytest output.
• Performed a self-review and completed the contribution checklist.
• Manually verified local E2E tests for global, us, and eu endpoints.

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

[adk-bot]

Response from ADK Triaging Agent

Hello @kaligautier, thank you for your contribution!

Before we can merge this PR, you'll need to sign the Contributor License Agreement (CLA). It seems like the CLA check has failed. You can find more information and sign the CLA at https://cla.developers.google.com/.

Thanks!

[gemini-code-assist]

Code Review

This pull request adds support for regional Discovery Engine endpoints by introducing a helper function, _build_client_options, to parse the location from the resource ID and construct the appropriate api_endpoint for the SearchServiceClient, while preserving an existing quota_project_id. While the implementation includes new unit tests, the parsing logic for the location uses a permissive regular expression that is vulnerable to Server-Side Request Forgery (SSRF), potentially allowing an attacker to redirect API requests and steal Google Cloud credentials. It is recommended to tighten the regular expression to only allow valid location characters to address this security concern.

[kaligautier]

@llalitkumarrr si working