New Issue Checklist
Issue Description
The documentation for directAccess states that the option defaults to false, but it has defaulted to true since Parse Server 6. The contradiction sits inside a single JSDoc block, where the prose and the :DEFAULT: annotation disagree:
// src/Options/index.js
/* Set to `true` if Parse requests within the same Node.js environment as Parse Server should be routed to Parse Server directly instead of via the HTTP interface. Default is `false`.
<br><br>
If set to `false` then Parse requests within the same Node.js environment as Parse Server are executed as HTTP requests sent to Parse Server via the `serverURL`. …
<br><br>
⚠️ In environments where multiple Parse Server instances run behind a load balancer and Parse requests within the current Node.js environment should be routed via the load balancer and distributed as HTTP requests among all instances via the `serverURL`, this should be set to `false`.
:DEFAULT: true */
directAccess: ?boolean;
The true default is deliberate. It was announced as deprecation DEPPS2 and applied in Parse Server 6 (#8269). Only the prose was left behind, and it propagates: resources/buildConfigDefinitions.js copies it into src/Options/Definitions.js, which is what parse-server --help and the generated options documentation render. So every operator reading the documentation is told the opposite of what the server does.
The stale sentence is worse than a plain typo because of the ⚠️ paragraph directly beneath it. Deployments running multiple instances behind a load balancer are told they "should set this to false", while the sentence above assures them false is already the default. Those operators are the ones the warning is aimed at, and the documentation tells them no action is required, when in fact they need an explicit override.
For completeness, what the option controls: with directAccess enabled, ParseServer installs ParseServerRESTController as the SDK's REST controller.
// src/ParseServer.ts
if (process.env.PARSE_SERVER_ENABLE_EXPERIMENTAL_DIRECT_ACCESS === '1' || directAccess) {
Parse.CoreManager.setRESTController(ParseServerRESTController(appId, appRouter));
}That controller builds a request object and calls router.tryRouteRequest(method, path, request), so a Parse.Query in Cloud Code never traverses the Express stack and middleware mounted with app.use does not run for it. That is the intended design and the point of the feature. The issue is only that operators are told the mode is off by default, so they never get to weigh it.
Steps to reproduce
- Run
parse-server --help and read the directAccess entry, or open the generated options documentation.
- Start Parse Server without setting
directAccess and read the resolved value, for example Config.get(appId).directAccess.
Actual Outcome
The documentation says the default is false. The resolved value is true.
Expected Outcome
The documentation matches the behavior. Since the true default is intentional per DEPPS2, the fix is to the text, not the default: drop the "Default is false." sentence and state that the default is true, so the ⚠️ load-balancer guidance reads as an action rather than a reassurance.
Happy to open a PR.
Environment
Server
- Parse Server version:
9.10.1-alpha.6
- Operating system:
macOS 15.5
- Local or remote host:
local
Database
- System (MongoDB or Postgres):
MongoDB
- Database version:
8.0
- Local or remote host:
local
Client
- SDK (iOS, Android, JavaScript, PHP, Unity, etc):
not applicable, server configuration
- SDK version:
not applicable
Logs
No error is produced. The documented default is simply wrong.
New Issue Checklist
Issue Description
The documentation for
directAccessstates that the option defaults tofalse, but it has defaulted totruesince Parse Server 6. The contradiction sits inside a single JSDoc block, where the prose and the:DEFAULT:annotation disagree:The
truedefault is deliberate. It was announced as deprecationDEPPS2and applied in Parse Server 6 (#8269). Only the prose was left behind, and it propagates:resources/buildConfigDefinitions.jscopies it intosrc/Options/Definitions.js, which is whatparse-server --helpand the generated options documentation render. So every operator reading the documentation is told the opposite of what the server does.The stale sentence is worse than a plain typo because of the
⚠️paragraph directly beneath it. Deployments running multiple instances behind a load balancer are told they "should set this tofalse", while the sentence above assures themfalseis already the default. Those operators are the ones the warning is aimed at, and the documentation tells them no action is required, when in fact they need an explicit override.For completeness, what the option controls: with
directAccessenabled,ParseServerinstallsParseServerRESTControlleras the SDK's REST controller.That controller builds a request object and calls
router.tryRouteRequest(method, path, request), so aParse.Queryin Cloud Code never traverses the Express stack and middleware mounted withapp.usedoes not run for it. That is the intended design and the point of the feature. The issue is only that operators are told the mode is off by default, so they never get to weigh it.Steps to reproduce
parse-server --helpand read thedirectAccessentry, or open the generated options documentation.directAccessand read the resolved value, for exampleConfig.get(appId).directAccess.Actual Outcome
The documentation says the default is
false. The resolved value istrue.Expected Outcome
The documentation matches the behavior. Since the
truedefault is intentional perDEPPS2, the fix is to the text, not the default: drop the "Default isfalse." sentence and state that the default istrue, so the⚠️load-balancer guidance reads as an action rather than a reassurance.Happy to open a PR.
Environment
Server
9.10.1-alpha.6macOS 15.5localDatabase
MongoDB8.0localClient
not applicable, server configurationnot applicableLogs
No error is produced. The documented default is simply wrong.