Repository navigation
Datastore Query generates Bad Request with select+filter attached. #1016
Description
Activity
Thanks for reporting! @pcostell is this us or an issue of indexes?
- addedtype: bugError or flaw in code with unintended results or allowing sub-optimal usage patterns.Error or flaw in code with unintended results or allowing sub-optimal usage patterns.api: datastoreIssues related to the Datastore API.Issues related to the Datastore API.
on Dec 11, 2015 Hi - some added information - and maybe this is why there is this issue... The "id" column that I'm trying to filter/select is not indexed. Does the gcloud lib support tagging fields as indexed?
Yes, the id must be indexed, but it should be indexed by default. In fact
if you get results where you query for id = ... then it is indexed.
However, the issue you are hitting is that you can't project something
involved in an equality:Is there not more information in the returned error message? I think the
error that should be returned calls this out explicitly.On Fri, Dec 11, 2015, 3:33 PM Christopher Eaton [email protected]
wrote:Hi - some added information - and maybe this is why there is this issue...
The "id" column that I'm trying to filter/select is not indexed. Does
the gcloud lib support tagging fields as indexed?—
Reply to this email directly or view it on GitHub
#1016 (comment)
.Hi @pcostell,
Unfortunately there isn't a message like that, here's the err object in full minus my gc project id:{"errors":[],"code":400,"message":"Bad Request","response":{"statusCode":400,"body":{"type":"Buffer","data":[67,97,110,110,111,116,32,117,115,101,32,112,114,111,106,101,99,116,105,111,110,32,111,110,32,97,32,112,114,111,112,101,114,116,121,32,119,105,116,104,32,97,110,32,101,113,117,97,108,105,116,121,32,102,105,108,116,101,114,46]},"headers":{"vary":"X-Origin, Origin,Accept-Encoding","content-type":"text/html; charset=UTF-8","date":"Fri, 11 Dec 2015 23:38:46 GMT","expires":"Fri, 11 Dec 2015 23:38:46 GMT","cache-control":"private, max-age=0","x-content-type-options":"nosniff","x-frame-options":"SAMEORIGIN","x-xss-protection":"1; mode=block","server":"GSE","alternate-protocol":"443:quic,p=0","alt-svc":"clear","accept-ranges":"none","connection":"close"},"request":{"uri":{"protocol":"https:","slashes":true,"auth":null,"host":"www.googleapis.com","port":443,"hostname":"www.googleapis.com","hash":null,"search":null,"query":null,"pathname":"/datastore/v1beta2/datasets/xxxx/runQuery","path":"/datastore/v1beta2/datasets/xxxx/runQuery","href":"https://www.googleapis.com/datastore/v1beta2/datasets/xxxx/runQuery"},"method":"POST","headers":{"Content-Type":"application/x-protobuf","Authorization":"Bearer xxxx","User-Agent":"gcloud-node/0.24.1","content-length":68}}}}However, the issue you are hitting is that you can't project something involved in an equality:
Thanks! That's it, if I change the op to something other than equality it works.
Turns out the data of the response body is an ascii array which says:
"'Cannot use projection on a property with an equality filter.'"@stephenplusplus - maybe the body should get parsed into a string?
@eddavisson - any idea why the JSON is getting sent like this?I believe the body is being returned as a Buffer because that's just how the request library we're using does it. We wrap that raw response and return it in our custom
ApiErrortype.I played around with a 412 - Precondition Failed error. The response body is a buffer, but stringified (
err.response.body.toString()) is something likeno matching index found.When we return our custom ApiError to the user, we use the HTTP status message as the "message" to associate with the error. When youconsole.logor throw an error, the message is what's displayed. Maybe we should use that in combination with the parsedresponse.body, if it exists?In this case, it would look like:
console.log(err); // Precondition Failed - no matching index found.- added a commit that references this issue
on Jan 17, 2023 - added a commit that references this issue
on Jul 23, 2025 - added a commit that references this issue
on Jan 28, 2026 - added a commit that references this issue
on Feb 5, 2026 - added a commit that references this issue
on Feb 17, 2026 - added a commit that references this issue
on Feb 24, 2026 - added a commit that references this issue
on Mar 27, 2026
I have a pretty basic entity and am attempting to leverage a query to select it. But when I use the "select" function on the query (in conjunction with a "filter"), and then run the query, it generates a Bad Request error. Removing the "select" allows the query to run ok.
I can run either select or filter independently and they both work ok.
Failing query:
Creates Error:
Running
or
works fine and returns the results expected.