-
-
Notifications
You must be signed in to change notification settings - Fork 4.8k
Inconsistent config validation when starting a server instance via CLI vs. API #8673
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Thanks for opening this issue!
|
Just stumbled upon this trying to configure 'auth' option in config.json, server starting from CLI (default docker image). |
Does this still occur with the latest alpha version of Parse Server? |
I see 'auth' issue is fixed in 5.5.3, here https://github.com/parse-community/parse-server/pull/8669/files thanks! |
Is the configuration options validation that is performed on starting the server via CLI also performed when starting the server via API and if so, which parse-server version fixed that? |
I assumed from your comment that the issue has been fixed; I'll re-open. |
New Issue Checklist
Issue Description
When starting a Parse Server instance via CLI, all config parameters are extensively checked and warnings/errors are logged if any issues are found (see Definitions.js). These same checks are not performed when creating a server instance via API.
This can lead to situations where a server setup is created and tested via API that later fails when started via CLI.
Ideally the same checks are performed when starting via API and CLI, so possible configuration issues can be detected early on and are consistent independent of how the server is started.
As there might be non-CLI installations that wouldn't pass the existing CLI checks, this should at least initially be an optional feature.
Steps to reproduce
On 5.5.1, the following config can be used to reproduce:
Passing this as config.json on the CLI results in an error (on v5.3 - v5.5.1).
Starting via API works:
Actual Outcome
The CLI gave following error (meanwhile addressed: #8666)
Error: [object Object] should be a comma separated string or an array
Expected Outcome
I expected the server to run fine when started via CLI instead of API (as it did before).
Environment
Server
Database
Client
Logs
The text was updated successfully, but these errors were encountered: