Skip to content

SecretManagerClient and ParameterManagerClient auth_token paths fail at runtime #5370

Closed

Description

@shaun0927

🔴 Required Information

Describe the Bug:
SecretManagerClient(auth_token=...) and ParameterManagerClient(auth_token=...) both fail immediately at runtime because they instantiate google.auth.credentials.Credentials(...) directly. That class is abstract, so the public auth_token path raises a TypeError before the underlying Google Cloud client is even constructed.

There is also a closely related contract mismatch in SecretManagerClient: its docstring says service_account_json and auth_token together should raise ValueError, but the implementation currently accepts both inputs and silently prefers service_account_json.

Steps to Reproduce:

  1. Check out the current main branch (or latest stable v1.31.0).
  2. Install the project dependencies (I reproduced this in a local checkout with Python 3.11.15).
  3. Run the following snippet:
from unittest.mock import MagicMock, patch

from google.adk.integrations.secret_manager.secret_client import SecretManagerClient
from google.adk.integrations.parameter_manager.parameter_client import ParameterManagerClient

with patch("google.cloud.secretmanager.SecretManagerServiceClient", return_value=MagicMock()):
    SecretManagerClient(auth_token="test-token")

with patch("google.cloud.parametermanager_v1.ParameterManagerClient", return_value=MagicMock()):
    ParameterManagerClient(auth_token="test-token")
  1. (Optional) Run this second snippet to see the conflicting-input behavior in SecretManagerClient:
import json
from unittest.mock import MagicMock, patch

from google.adk.integrations.secret_manager.secret_client import SecretManagerClient

with patch("google.cloud.secretmanager.SecretManagerServiceClient", return_value=MagicMock()), \
     patch("google.oauth2.service_account.Credentials.from_service_account_info", return_value=MagicMock()):
    SecretManagerClient(
        service_account_json=json.dumps({"type": "service_account"}),
        auth_token="test-token",
    )

Expected Behavior:

  • auth_token should create a concrete credential object and allow both helpers to initialize successfully.
  • SecretManagerClient should reject service_account_json + auth_token together, matching its own documented contract.

Observed Behavior:
The auth_token path fails with:

TypeError: Can't instantiate abstract class Credentials with abstract method refresh

And SecretManagerClient(service_account_json=..., auth_token=...) succeeds instead of raising.

Environment Details:

  • ADK Library Version (pip show google-adk): reproduced on latest stable v1.31.0 and latest main (36ab8f128c0281e44c2120a17de91e081f2232b1 as of 2026-04-17)
  • Desktop OS:** macOS
  • Python Version (python -V): 3.11.15

Model Information:

  • Are you using LiteLLM: No
  • Which model is being used: N/A (this bug reproduces before any model call)

🟡 Optional Information

Regression:
These helpers were introduced recently and the broken behavior is still present in the latest stable release and latest main.

Logs:

TypeError: Can't instantiate abstract class Credentials with abstract method refresh

Additional Context:
The existing token-path unit tests currently mock the google.auth.credentials.Credentials constructor, which masks the runtime failure:

  • tests/unittests/integrations/secret_manager/test_secret_client.py
  • tests/unittests/integrations/parameter_manager/test_parameter_client.py

I have a local patch ready that switches both helpers to a concrete token credential type and adds regression coverage that uses the real credentials constructor path.

Minimal Reproduction Code:

from unittest.mock import MagicMock, patch
from google.adk.integrations.secret_manager.secret_client import SecretManagerClient

with patch("google.cloud.secretmanager.SecretManagerServiceClient", return_value=MagicMock()):
    SecretManagerClient(auth_token="test-token")

How often has this issue occurred?:

  • Always (100%)

Activity

  1. added
    auth[Component] This issue is related to authorization
    on Apr 17, 2026
  2. added theissue type on Apr 17, 2026
  3. surajksharma07 commented on Apr 22, 2026

    @surajksharma07
    Collaborator

    @shaun0927 Thanks for the thorough report and for already tracing it down to the root cause.
    you're right that google.auth.credentials.Credentials is abstract, so the auth_token path crashes before the GCP client even initializes.

    As a workaround -
    while the PR is under review, try switching both helpers to google.oauth2.credentials.Credentials(token=auth_token) — no .refresh() call needed since the token is already valid.

    Could you confirm that holds up on your end?

    Once verified, running autoformat.sh on PR #5371 should clear the only remaining review blocker — the implementation itself looks good, it's just the formatting pass that's pending!

    Team is looking more into it.
    Thanks!

  4. shaun0927 commented on Apr 22, 2026

    @shaun0927
    ContributorAuthor

    @surajksharma07 Confirmed — google.oauth2.credentials.Credentials(token=auth_token) is exactly the approach #5371 takes, and the 17 tests in tests/unittests/integrations/{secret,parameter}_manager pass locally against that change. Just pushed a rebase + autoformat.sh pass to #5371 so pyink-check is green. Ready for re-review whenever you have time.

  5. surajksharma07 commented on Apr 24, 2026

    @surajksharma07
    Collaborator

    @shaun0927 google.oauth2.credentials.Credentials(token=auth_token) with no .refresh() call is the right concrete credential path.
    17/17 passing gives solid coverage across both client types, and a clean pyink check means #5371 has no remaining blockers.

    Team is looking more into it.
    Thanks!

  6. added
    needs review[Status] The PR/issue is awaiting review from the maintainer
    and removed
    request clarification[Status] The maintainer need clarification or more information from the author
    on Apr 24, 2026
  7. surajksharma07 commented on Apr 24, 2026

    @surajksharma07
    Collaborator

    @seanzhou1023 Please have a look into it once.

  8. added a commit that references this issue on Jun 29, 2026
    46a2181
  9. added a commit that references this issue on Aug 11, 2026
    4a1eda7
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Labels

auth[Component] This issue is related to authorizationneeds review[Status] The PR/issue is awaiting review from the maintainer

Type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions