You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
GitHub Actions workflow discussion_answering.yml fails on Q&A discussion creation with a Vertex AI 404 for gemini-3.5-flash #6104
google.genai.errors.ClientError: 404 NOT_FOUND.
Publisher Model `projects/***/locations/***/publishers/google/models/gemini-3.5-flash`
was not found or your project does not have access to it.
The failing step is Run Answering Script in ADK Answering Agent for Discussions. The workflow sets GOOGLE_GENAI_USE_VERTEXAI=1, and the model is hardcoded in:
This looks similar to #5696, but that issue covered triage workflows using Gemini Developer API. This failure is in the discussion answering workflow using Vertex AI.
Possible cause: GOOGLE_CLOUD_LOCATION may point to a region where gemini-3.5-flash is unavailable, or the Actions GCP project/service account does not have access to that model. Current docs list gemini-3.5-flash availability for global, us, and eu.
Hi @ftnext , Thanks for flagging this model routing issue — the availability gap for the hardcoded gemini-3.5-flash under regional endpoints is clearly confirmed, and running the workflow without targeting a global endpoint immediately fires the 404 with no other setup needed.
The approach in PR #6113 (making the discussion-answering model configurable rather than hardcoding it, while keeping the default configuration flexible) looks like exactly the right fix. This allows users to either opt into widely supported models that exist in standard regional endpoints, or supply their own custom model parameters.
Could you also confirm the configuration override holds for your local runner environment — specifically that you can successfully specify an alternate model (or apply the "global" location override to keep using gemini-3.5-flash) — and verify that this setup successfully unblocks execution on your end?
Activity
sanketpatil06 commentedon Jun 16, 2026
Hi @ftnext , Thanks for flagging this model routing issue — the availability gap for the hardcoded
gemini-3.5-flashunder regional endpoints is clearly confirmed, and running the workflow without targeting a global endpoint immediately fires the 404 with no other setup needed.The approach in PR #6113 (making the discussion-answering model configurable rather than hardcoding it, while keeping the default configuration flexible) looks like exactly the right fix. This allows users to either opt into widely supported models that exist in standard regional endpoints, or supply their own custom model parameters.
Could you also confirm the configuration override holds for your local runner environment — specifically that you can successfully specify an alternate model (or apply the
"global"location override to keep usinggemini-3.5-flash) — and verify that this setup successfully unblocks execution on your end?ftnext commentedon Jun 26, 2026
I tested this locally with a Vertex AI-enabled GCP project.
Confirmed:
LLM_MODEL_NAMEoverride is applied to the discussion answering agent.LLM_MODEL_NAME=gemini-3.5-flashandGOOGLE_CLOUD_LOCATION=global, the actual answering agent loads withroot_agent.model == "gemini-3.5-flash".The PR's default model of
gemini-2.5-flashmay not be safe for this agent's current mixed tool configuration.fix: make discussion answering model configurable
fix: make discussion answering model configurable