Summary
agentplatform (shipped in google-cloud-aiplatform) exposes
client.rag.ask_contexts(). Every call returns 400 INVALID_ARGUMENT with no
field named.
This does not appear to be a client defect. I checked the request the SDK builds
against the discovery schema and it matches. The same request sent by hand fails
identically, and the v1 form of the method answers:
501 UNIMPLEMENTED
"Operation is not implemented, or supported, or enabled."
So the question is whether AskContexts requires allowlisting, and if so whether
the SDK should surface the method (or raise something more useful) until it is
generally served.
Environment
google-cloud-aiplatform 1.165.1 (also reproduced on 1.163.0)
google-genai 2.16.0
- Python 3.13
- Regions tested: us-west1, us-central1, us-east4, europe-west4
What I measured
Live RAG corpus in us-west1, 4 documents, state ACTIVE. Same credentials and
same client for every row.
| probe |
result |
retrieve_contexts, same corpus, creds, region |
OK, 4 chunks |
ask_contexts() via the SDK |
400 INVALID_ARGUMENT, no field named |
raw REST, .../locations/L:askContexts |
400, identical |
body {"query": {...}} only (minimal valid per schema) |
400 |
body {} |
400 |
| body naming a corpus that does not exist |
400, identical to the valid one |
| body with an unknown field |
400 Unknown name "zzz": Cannot find field |
| us-central1, us-east4, europe-west4 |
400 in all three |
same method on v1 |
501 UNIMPLEMENTED |
control: retrieveContexts with {} |
400 "request must set datasource." |
Two rows are the interesting ones:
- The endpoint parses the body, because it names an unknown field precisely.
- It never reaches corpus validation, because a nonexistent corpus and a
valid corpus produce byte-identical errors.
And the control shows the RAG service returns specific, actionable errors in this
region when it is actually serving a method.
The request the SDK builds is schema-correct
GoogleCloudAiplatformV1beta1AskContextsRequest declares exactly {query, tools}.
That is what the SDK sends, and the corpus does reach the server inside tools:
from agentplatform._genai import rag, types as T
from google.genai import types as G
CORPUS = "projects/PROJECT/locations/us-west1/ragCorpora/CORPUS_ID"
tools = [G.Tool(retrieval=G.Retrieval(vertex_rag_store=G.VertexRagStore(
rag_resources=[G.VertexRagStoreRagResource(rag_corpus=CORPUS)])))]
params = T._AskContextsRequestParameters(
query=T.RagQuery(text="example question"),
config=T.AskContextsConfig(tools=tools))
d = rag._AskContextsRequestParameters_to_vertex(params)
d.pop("config", None) # the call site does this
print(sorted(d)) # ['query', 'tools']
print(CORPUS in str(d)) # True
Reproduction
import agentplatform
from agentplatform._genai import types as T
from google.genai import types as G
c = agentplatform.Client(project="PROJECT", location="us-west1")
CORPUS = "projects/PROJECT/locations/us-west1/ragCorpora/CORPUS_ID"
# works
c.rag.retrieve_contexts(
vertex_rag_store=G.VertexRagStore(
rag_resources=[G.VertexRagStoreRagResource(rag_corpus=CORPUS)]),
query=T.RagQuery(text="example question"))
# 400 INVALID_ARGUMENT, no field named
c.rag.ask_contexts(
query=T.RagQuery(text="example question"),
config=T.AskContextsConfig(tools=[G.Tool(retrieval=G.Retrieval(
vertex_rag_store=G.VertexRagStore(
rag_resources=[G.VertexRagStoreRagResource(rag_corpus=CORPUS)])))]))
And the v1 form, which is the clearest signal:
POST https://us-west1-aiplatform.googleapis.com/v1/projects/PROJECT/locations/us-west1:askContexts
{"query": {"text": "example question"}}
501 {"error": {"code": 501,
"message": "Operation is not implemented, or supported, or enabled.",
"status": "UNIMPLEMENTED"}}
Questions
- Is
AskContexts allowlisted or otherwise gated? If so, what is the path to
enablement?
- If it is not generally available, could the v1beta1 endpoint return the same
UNIMPLEMENTED that v1 returns, instead of a generic INVALID_ARGUMENT that
sends callers looking for a bad field?
Note on a non-issue
While investigating I noticed the built path is
projects/P/locations/L/:askContexts, with a separator before the colon. That is
not the cause: retrieve_contexts builds projects/P/locations/L/:retrieveContexts
in exactly the same way and works. Mentioning it only so nobody else spends time
on it.
Summary
agentplatform(shipped ingoogle-cloud-aiplatform) exposesclient.rag.ask_contexts(). Every call returns400 INVALID_ARGUMENTwith nofield named.
This does not appear to be a client defect. I checked the request the SDK builds
against the discovery schema and it matches. The same request sent by hand fails
identically, and the
v1form of the method answers:So the question is whether
AskContextsrequires allowlisting, and if so whetherthe SDK should surface the method (or raise something more useful) until it is
generally served.
Environment
google-cloud-aiplatform1.165.1 (also reproduced on 1.163.0)google-genai2.16.0What I measured
Live RAG corpus in us-west1, 4 documents, state ACTIVE. Same credentials and
same client for every row.
retrieve_contexts, same corpus, creds, regionask_contexts()via the SDK.../locations/L:askContexts{"query": {...}}only (minimal valid per schema){}Unknown name "zzz": Cannot find fieldv1retrieveContextswith{}"request must set datasource."Two rows are the interesting ones:
valid corpus produce byte-identical errors.
And the control shows the RAG service returns specific, actionable errors in this
region when it is actually serving a method.
The request the SDK builds is schema-correct
GoogleCloudAiplatformV1beta1AskContextsRequestdeclares exactly{query, tools}.That is what the SDK sends, and the corpus does reach the server inside
tools:Reproduction
And the v1 form, which is the clearest signal:
Questions
AskContextsallowlisted or otherwise gated? If so, what is the path toenablement?
UNIMPLEMENTEDthat v1 returns, instead of a genericINVALID_ARGUMENTthatsends callers looking for a bad field?
Note on a non-issue
While investigating I noticed the built path is
projects/P/locations/L/:askContexts, with a separator before the colon. That isnot the cause:
retrieve_contextsbuildsprojects/P/locations/L/:retrieveContextsin exactly the same way and works. Mentioning it only so nobody else spends time
on it.