Repository navigation
SecretManagerClient and ParameterManagerClient auth_token paths fail at runtime #5370
Description
🔴 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:
- Check out the current
mainbranch (or latest stablev1.31.0). - Install the project dependencies (I reproduced this in a local checkout with Python 3.11.15).
- 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")- (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_tokenshould create a concrete credential object and allow both helpers to initialize successfully.SecretManagerClientshould rejectservice_account_json+auth_tokentogether, 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.0and latestmain(36ab8f128c0281e44c2120a17de91e081f2232b1as 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.pytests/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
surajksharma07 commentedon Apr 22, 2026
@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!
shaun0927 commentedon Apr 22, 2026
@surajksharma07 Confirmed —
google.oauth2.credentials.Credentials(token=auth_token)is exactly the approach #5371 takes, and the 17 tests intests/unittests/integrations/{secret,parameter}_managerpass locally against that change. Just pushed a rebase +autoformat.shpass to #5371 sopyink-checkis green. Ready for re-review whenever you have time.surajksharma07 commentedon Apr 24, 2026
@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!
surajksharma07 commentedon Apr 24, 2026
@seanzhou1023 Please have a look into it once.
fix: restore auth_token initialization for secret and parameter manag…
fix: restore auth_token initialization for secret and parameter manag…