Skip to content

Conversation

@zaphod72
Copy link
Contributor

@zaphod72 zaphod72 commented Nov 22, 2025

Summary

This PR modifies the GoogleSecretManagerSettingsSource to gracefully handle access errors. Instead of raising a KeyError when a specific secret cannot be accessed (e.g., due to permission issues), it now returns None. This allows pydantic-settings to continue processing and potentially fall back to default values or other configured settings sources.

Changes

  • pydantic_settings/sources/providers/gcp.py: Updated GoogleSecretManagerMapping.__getitem__ to catch exceptions during secret retrieval and return None instead of raising KeyError.
  • tests/test_source_gcp_secret_manager.py:
    • Updated test_secret_manager_mapping_getitem_error to verify that None is returned for inaccessible secrets.
    • Added test_pydantic_base_settings_with_default_value to ensure that fields fall back to their default values when the secret source returns None.
    • Added test_secret_manager_mapping_list_secrets_error to verify that errors during the listing of secrets are still propagated correctly.

Motivation

#710
Previously, if the application attempted to access a secret it didn't have permission to view, the settings loading process would crash with a KeyError. This behavior prevented the use of default values or alternative sources for those fields. By returning None, we align with the expected behavior where a missing or inaccessible setting allows the next priority source (or default value) to take effect.

Darren Kennedy added 3 commits November 22, 2025 00:12
…date tests to reflect this behavior, and add a test for `list_secrets` error handling.
@zaphod72 zaphod72 changed the title bugfix: Return None for inaccessible GCP Secret Manager secrets, update tests to reflect this behavior, and add a test for list_secrets error handling. bugfix: Return None for inaccessible GCP Secret Manager secrets Nov 22, 2025
except Exception:
raise KeyError(key)
# If we can't access the secret, we return None
self._loaded_secrets[key] = None
Copy link
Member

Choose a reason for hiding this comment

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

This is a breaking change. Not sure whether this is the correct behaviour.

Probably we can add this behaviour in V2 by a flag that is disabled by default.

@ezwiefel what do you think?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I dug through all the code paths I could find that would get to that point and didn't see where throwing the KeyError would be useful. I certainly could be missing something.

Copy link
Member

Choose a reason for hiding this comment

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

agree KeyError is not useful. let's merge the PR and see.

@hramezani hramezani merged commit 41f3413 into pydantic:main Nov 24, 2025
19 checks passed
@hramezani
Copy link
Member

Thanks @zaphod72

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