[PD1-66] - Allow api keys mapping to fetch data across tenants #14

olivierpichon · 2025-12-01T07:53:22Z

We want to allow the SDK to fetch data from multiple tenants using API KEYS fetched via AWS Secret manager or env variable API_KEYS_MAPPING for local development.
Once the mapping is fetched, it is cached. Providing the SDK with an api_key as argument to its initializer takes precedence over the new added method. Some test cases make sure this is the case.

linear · 2025-12-01T07:53:24Z

PD1-66 Data Backbone Algorithm Repository

Define the interface Data Backbone Algorithm Python interface.
Create a repository for algorithms. For example, create a private Python package registry or use AWS ECR.
Collaboration with rpourghasemi to add the first algorithm

gemini-code-assist · 2025-12-01T07:53:39Z

Summary of Changes

Hello @olivierpichon, 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 SDK's capability to manage API keys by introducing a flexible mechanism to retrieve them from centralized sources like AWS Secrets Manager or local environment configurations. This change significantly improves the SDK's adaptability for multi-tenant deployments and streamlines API key management, while ensuring backward compatibility and explicit control over key provisioning.

Highlights

Multi-tenant API Key Management: Introduced a new service to fetch API keys from AWS Secrets Manager or a local environment variable mapping, enabling the SDK to operate across multiple tenants dynamically.
API Key Precedence: The SDK now prioritizes API keys provided directly to the constructor, then from the CVEC_API_KEY environment variable, and finally from the new API key mapping service.
Dependency Updates: Added boto3 and related AWS SDK dependencies to pyproject.toml and poetry.lock to support integration with AWS Secrets Manager.
Comprehensive Testing: New unit tests have been added to validate the API key loading logic, including precedence rules and error handling for the new service.

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.

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

The pull request introduces a new API key service that allows fetching API keys from AWS Secrets Manager or local environment variables, enhancing flexibility for multi-tenant data fetching. The implementation includes a caching mechanism for API keys and a clear priority for loading sources (AWS Secrets Manager over local environment variables). Comprehensive unit tests have been added for the new service and its integration into the CVec client, covering various scenarios including success, failure, and precedence rules. The poetry.lock and pyproject.toml files were updated to reflect the new boto3 dependency.

Overall, the changes are well-designed and thoroughly tested, significantly improving the API key management within the SDK.

gemini-code-assist · 2025-12-01T07:55:18Z

src/cvec/cvec.py

+            try:
+                self._api_key = get_api_key_for_host(self.host)
+                if self._api_key:
+                    logger.info(f"API key loaded from mapping service for host: {self.host}")
+            except ValueError as e:
+                # Log the error from the service, but we'll raise our own error below
+                logger.debug(f"Failed to load API key from service: {e}")
+
        if not self._api_key:
            raise ValueError(
-                "CVEC_API_KEY must be set either as an argument or environment variable"
+                "CVEC_API_KEY must be set either as an argument, environment variable, "
+                "or available in the API keys mapping (AWS_API_KEYS_SECRET or API_KEYS_MAPPING)"
            )


The current error handling logs a specific ValueError from get_api_key_for_host at debug level and then raises a more generic ValueError. While the generic message is comprehensive, propagating the specific service error message can provide more immediate and actionable feedback to the user about why the API key could not be loaded from the service.

Consider including the service_error_message in the final ValueError to give more context.

Suggested change

try:

self._api_key = get_api_key_for_host(self.host)

if self._api_key:

logger.info(f"API key loaded from mapping service for host: {self.host}")

except ValueError as e:

# Log the error from the service, but we'll raise our own error below

logger.debug(f"Failed to load API key from service: {e}")

if not self._api_key:

raise ValueError(

"CVEC_API_KEY must be set either as an argument or environment variable"

"CVEC_API_KEY must be set either as an argument, environment variable, "

"or available in the API keys mapping (AWS_API_KEYS_SECRET or API_KEYS_MAPPING)"

)

service_error_message = None

try:

self._api_key = get_api_key_for_host(self.host)

if self._api_key:

logger.info(f"API key loaded from mapping service for host: {self.host}")

except ValueError as e:

service_error_message = str(e)

logger.debug(f"Failed to load API key from service: {service_error_message}")

if not self._api_key:

error_msg = (

"CVEC_API_KEY must be set either as an argument, environment variable, "

"or available in the API keys mapping (AWS_API_KEYS_SECRET or API_KEYS_MAPPING)"

)

if service_error_message:

error_msg += f". Service error: {service_error_message}"

raise ValueError(error_msg)

tenants using API_KEYS fetched via AWS Secret manager or env variable `API_KEYS_MAPPING` for local development. Once the mapping is fetched, it is cached. Providing the SDK with an `api_key` as argument to its initializer as we used to do takes precedence over the new added method. Some test cases make sure this is the case.

joshuanapoli

Can we put the api_key_service somewhere else? The cvec-python SDK is also for customer access (and it is published publicly on PyPI). I don't think that they should see this internal key-distribution detail. We could create a private repo that extends the public SDK with private features.

gemini-code-assist bot reviewed Dec 1, 2025

View reviewed changes

olivierpichon force-pushed the op/api_keys branch 2 times, most recently from 5312bcd to f4c6718 Compare December 1, 2025 08:01

olivierpichon force-pushed the op/api_keys branch from f4c6718 to 3742963 Compare December 1, 2025 08:04

olivierpichon changed the title ~~[PD1-66] -Allow api keys mapping to fetch data across tenants~~ [PD1-66] - Allow api keys mapping to fetch data across tenants Dec 1, 2025

joshuanapoli reviewed Dec 1, 2025

View reviewed changes

joshuanapoli closed this Dec 16, 2025

joshuanapoli deleted the op/api_keys branch December 16, 2025 20:34

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

[PD1-66] - Allow api keys mapping to fetch data across tenants #14

[PD1-66] - Allow api keys mapping to fetch data across tenants #14

Uh oh!

olivierpichon commented Dec 1, 2025 •

edited

Loading

Uh oh!

linear bot commented Dec 1, 2025

Uh oh!

gemini-code-assist bot commented Dec 1, 2025

Uh oh!

gemini-code-assist bot left a comment

Uh oh!

gemini-code-assist bot Dec 1, 2025

Uh oh!

joshuanapoli left a comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

[PD1-66] - Allow api keys mapping to fetch data across tenants #14

[PD1-66] - Allow api keys mapping to fetch data across tenants #14

Uh oh!

Conversation

olivierpichon commented Dec 1, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

linear bot commented Dec 1, 2025

Uh oh!

gemini-code-assist bot commented Dec 1, 2025

Summary of Changes

Highlights

Footnotes

Uh oh!

gemini-code-assist bot left a comment

Choose a reason for hiding this comment

Code Review

Uh oh!

gemini-code-assist bot Dec 1, 2025

Choose a reason for hiding this comment

Uh oh!

joshuanapoli left a comment

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

olivierpichon commented Dec 1, 2025 •

edited

Loading