Environment details
- OS type and version: Linux (Vertex AI Agent Engine environment)
- Python version:
Python 3.11+
google-cloud-aiplatform version: 1.143.0
Steps to reproduce
- Create an agent via Google ADK exposing tools that generate or return visual artifacts (images/videos) using
tool_context.save_artifact().
- Instantiate and wrap the ADK agent into a Vertex AI SDK template using
AdkApp (from vertexai.agent_engines.templates.adk).
- Deploy this agent to Agent Engine (Vertex AI platform container mapping to Gemini Enterprise).
- Trigger any tool that saved an artifact from the UI chat.
Root Cause Analysis
The issue occurs because the application name used by the container falls back onto the ID assigned by the Cloud platform if not explicitly provided, while the Runner defaults to the name defined in the ADK App instance.
In AdkApp.set_up(), the fallback logic is as follows:
# AdkApp.set_up() fallback logic
if not self._tmpl_attrs.get("app_name"):
if "GOOGLE_CLOUD_AGENT_ENGINE_ID" in os.environ:
self._tmpl_attrs["app_name"] = os.environ.get(
"GOOGLE_CLOUD_AGENT_ENGINE_ID",
)
else:
self._tmpl_attrs["app_name"] = _DEFAULT_APP_NAME
However, the Runner created later defaults to app.name (the static default "app" in ADK if not overridden):
# Runner._validate_runner_params defaults to app.name
app_name = app_name or app.name # resolves to "app" instead of the ID
This creates a mismatch failure during session artifact reads in _convert_response_events.
Actual Behavior
-
Save Path evaluates using app.name (e.g., "app" or a custom name like "mova"):
GCS_BUCKET/app/{user_id}/{session_id}/artifact.png
-
Load Path evaluates using AdkApp._tmpl_attrs["app_name"] (e.g., the numerical ID assigned by Google Cloud):
GCS_BUCKET/8269664996770709504/{user_id}/{session_id}/artifact.png
Because strings like "app" and "8269664996770709504" on bucket paths do not map identically, files aren't found on state loads, and the Gemini Enterprise UI draws empty boxes or fails to render the media.
Moreover, if the user tries to use GOOGLE_CLOUD_AGENT_ENGINE_ID directly to solve the mismatch, the purely numerical ID causes Pydantic validation failures on boot because it is not a valid Python identifier (starts with a digit).
Expected Behavior
The AdkApp should ensure that the app_name in its template attributes matches the name of the ADK App being wrapped, or provide a clean way to synchronize them, rather than falling back to the numerical GOOGLE_CLOUD_AGENT_ENGINE_ID.
Workaround Applied
To fix this manually in user code, one can override _tmpl_attrs["app_name"] after calling super().set_up() in the custom AdkApp class:
class AgentEngineApp(AdkApp):
def set_up(self) -> None:
super().set_up()
# Enforce that AdkApp uses the same name as the ADK App
self._tmpl_attrs["app_name"] = adk_app.name
Environment details
Python 3.11+google-cloud-aiplatformversion:1.143.0Steps to reproduce
tool_context.save_artifact().AdkApp(fromvertexai.agent_engines.templates.adk).Root Cause Analysis
The issue occurs because the application name used by the container falls back onto the ID assigned by the Cloud platform if not explicitly provided, while the Runner defaults to the name defined in the ADK
Appinstance.In
AdkApp.set_up(), the fallback logic is as follows:However, the
Runnercreated later defaults toapp.name(the static default"app"in ADK if not overridden):This creates a mismatch failure during session artifact reads in
_convert_response_events.Actual Behavior
Save Path evaluates using
app.name(e.g.,"app"or a custom name like"mova"):GCS_BUCKET/app/{user_id}/{session_id}/artifact.pngLoad Path evaluates using
AdkApp._tmpl_attrs["app_name"](e.g., the numerical ID assigned by Google Cloud):GCS_BUCKET/8269664996770709504/{user_id}/{session_id}/artifact.pngBecause strings like
"app"and"8269664996770709504"on bucket paths do not map identically, files aren't found on state loads, and the Gemini Enterprise UI draws empty boxes or fails to render the media.Moreover, if the user tries to use
GOOGLE_CLOUD_AGENT_ENGINE_IDdirectly to solve the mismatch, the purely numerical ID causes Pydantic validation failures on boot because it is not a valid Python identifier (starts with a digit).Expected Behavior
The
AdkAppshould ensure that theapp_namein its template attributes matches thenameof the ADKAppbeing wrapped, or provide a clean way to synchronize them, rather than falling back to the numericalGOOGLE_CLOUD_AGENT_ENGINE_ID.Workaround Applied
To fix this manually in user code, one can override
_tmpl_attrs["app_name"]after callingsuper().set_up()in the customAdkAppclass: