New Issue Checklist
Issue Description
InstallationsRouter.handleFind and AudiencesRouter.handleFind override ClassesRouter.handleFind but drop its string-where decoding step, so a query sent with the documented POST + _method=GET override fails on /installations and /audiences while the identical query succeeds on /classes/_Installation.
ClassesRouter.handleFind decodes a where that arrives in the request body as a JSON string:
if (typeof body.where === 'string') {
try {
body.where = JSON.parse(body.where);
} catch {
throw new Parse.Error(Parse.Error.INVALID_JSON, 'where parameter is not valid JSON');
}
}
The two subclasses copy the body/options lines but not that block, so they only handle a where that arrives in the query string (decoded by ClassesRouter.JSONFromQuery). When the client uses the method override with an application/x-www-form-urlencoded body, body.where stays a string and is passed straight to rest.find. DatabaseController.validateQuery then runs Object.keys() over the string, walking it character by character, and the first index fails the key-name regex:
{"code":105,"error":"Invalid key name: 0"}
This is the same failure mode as the AggregateRouter pipeline handling that produced Invalid aggregate stage '0'.
The trigger is query size, not query shape. SDKs switch from GET to POST + _method=GET once the URL exceeds ~2 KB, so this only appears when an app queries /installations with a large enough constraint, for example an installationId $in list of roughly 41 or more ids. The same code path works for /users, /roles and /sessions, whose routers inherit ClassesRouter.handleFind unchanged.
Steps to reproduce
Any query long enough for the SDK to use the method override reproduces this. A minimal equivalent with curl:
# 1. POST + _method=GET against /installations -> error 105
curl -s -X POST \
-H 'X-Parse-Application-Id: myAppId' \
-H 'X-Parse-Master-Key: myMasterKey' \
-H 'Content-Type: application/x-www-form-urlencoded' \
--data-urlencode '_method=GET' \
--data-urlencode 'where={"installationId":{"$in":["af593bd0-cede-4b27-b0d0-1b48a025dc03"]}}' \
--data-urlencode 'limit=100' \
http://localhost:1337/parse/installations
# 2. Identical request against /classes/_Installation -> succeeds
curl -s -X POST \
-H 'X-Parse-Application-Id: myAppId' \
-H 'X-Parse-Master-Key: myMasterKey' \
-H 'Content-Type: application/x-www-form-urlencoded' \
--data-urlencode '_method=GET' \
--data-urlencode 'where={"installationId":{"$in":["af593bd0-cede-4b27-b0d0-1b48a025dc03"]}}' \
--data-urlencode 'limit=100' \
http://localhost:1337/parse/classes/_Installation
# 3. Same where as a GET query string against /installations -> succeeds
curl -s -G \
-H 'X-Parse-Application-Id: myAppId' \
-H 'X-Parse-Master-Key: myMasterKey' \
--data-urlencode 'where={"installationId":{"$in":["af593bd0-cede-4b27-b0d0-1b48a025dc03"]}}' \
http://localhost:1337/parse/installations
/audiences fails the same way.
Actual Outcome
1. {"code":105,"error":"Invalid key name: 0"}
2. {"results":[]}
3. {"results":[]}
Expected Outcome
All three return the query results. The method override is supported transport for a find, so /installations and /audiences should decode a string where from the body exactly as /classes/:className does.
Environment
Server
- Parse Server version:
9.10.0 (also present on alpha at 9.10.1-alpha.6; src/Routers/InstallationsRouter.js and src/Routers/AudiencesRouter.js are unchanged there)
- Operating system:
macOS 15.5 (Docker, node:22 image)
- Local or remote host:
local
Database
- System (MongoDB or Postgres):
MongoDB
- Database version:
7.0.31
- Local or remote host:
local
Client
- SDK (iOS, Android, JavaScript, PHP, Unity, etc):
reproduced with curl; originally hit from the Ruby SDK
- SDK version:
parse-stack-next 5.7.0
Logs
error: Invalid key name: 0 {"code":105,"stack":"Error: Invalid key name: 0
at .../parse-server/lib/Controllers/DatabaseController.js:208:13
at Array.forEach (<anonymous>)
at validateQuery (.../parse-server/lib/Controllers/DatabaseController.js:190:22)
at .../parse-server/lib/Controllers/DatabaseController.js:1238:11
at async _UnsafeRestQuery.runFind (.../parse-server/lib/RestQuery.js:785:19)"}
{"method":"POST","objectId":null,"body":{"keys":"installationId,appBuildNumber,appVersion","limit":"100","skip":"0","where":"{\"installationId\":{\"$in\":[\"af593bd0-cede-4b27-b0d0-1b48a025dc03\", ...]}}"},"installationId":null,"statusCode":400}
The logged body.where is still a string at the point the error is raised, which is the tell: ClassesRouter.handleFind mutates req.body.where into an object in place, so a request that went through the classes route would show a decoded object here.
I have a fix and can open a PR against alpha.
New Issue Checklist
Issue Description
InstallationsRouter.handleFindandAudiencesRouter.handleFindoverrideClassesRouter.handleFindbut drop its string-wheredecoding step, so a query sent with the documentedPOST+_method=GEToverride fails on/installationsand/audienceswhile the identical query succeeds on/classes/_Installation.ClassesRouter.handleFinddecodes awherethat arrives in the request body as a JSON string:The two subclasses copy the
body/optionslines but not that block, so they only handle awherethat arrives in the query string (decoded byClassesRouter.JSONFromQuery). When the client uses the method override with anapplication/x-www-form-urlencodedbody,body.wherestays a string and is passed straight torest.find.DatabaseController.validateQuerythen runsObject.keys()over the string, walking it character by character, and the first index fails the key-name regex:This is the same failure mode as the
AggregateRouterpipelinehandling that producedInvalid aggregate stage '0'.The trigger is query size, not query shape. SDKs switch from
GETtoPOST+_method=GETonce the URL exceeds ~2 KB, so this only appears when an app queries/installationswith a large enough constraint, for example aninstallationId$inlist of roughly 41 or more ids. The same code path works for/users,/rolesand/sessions, whose routers inheritClassesRouter.handleFindunchanged.Steps to reproduce
Any query long enough for the SDK to use the method override reproduces this. A minimal equivalent with curl:
/audiencesfails the same way.Actual Outcome
Expected Outcome
All three return the query results. The method override is supported transport for a
find, so/installationsand/audiencesshould decode a stringwherefrom the body exactly as/classes/:classNamedoes.Environment
Server
9.10.0(also present onalphaat9.10.1-alpha.6;src/Routers/InstallationsRouter.jsandsrc/Routers/AudiencesRouter.jsare unchanged there)macOS 15.5 (Docker, node:22 image)localDatabase
MongoDB7.0.31localClient
reproduced with curl; originally hit from the Ruby SDKparse-stack-next 5.7.0Logs
The logged
body.whereis still a string at the point the error is raised, which is the tell:ClassesRouter.handleFindmutatesreq.body.whereinto an object in place, so a request that went through the classes route would show a decoded object here.I have a fix and can open a PR against
alpha.