"ParseError: 130 option enableschemahooks is not supported." since 5.3.0

Parse Server 📡
#1

I have tried to upgrade parse-server from 5.2.8 to 5.3.0, but our integration tests fail. When testing cloud functions, some cloud functions (but not all) throw this error:

Expected a promise to be resolved but it was rejected with ParseError: 130 option enableschemahooks is not supported.
Stack:
at
at UserContext. (/parse/cloud/fooBar.test.js:99:9)
at
at processTicksAndRejections (node:internal/process/task_queues:96:5)

  databaseOptions: {
    enableSchemaHooks: false,
  },

We have this option set since upgrading from v4.5.0 to v5.2.1. Removing this option fixes the error.

Currently this fails on in Github Actions, not locally. Although the setup uses the same docker-compose setup. MongoDB version is 4.4.

Findings so far:

  • cloud functions seem to fail when using Parse.Query() or Parse.File().save()

Sharing my current state, maybe someone is working on this.

#2

This looks like a MongoDB error that is just wrapped in a Parse Error. Could it be that your MongoDB deployment doesn’t support that option? You may be using a different MongoDB version remotely vs. locally.

#3

Are you using GridStore or S3 for your files? I believe this config is being passed into GridStore and is not supported there

#4

@Frank500 did you resolve this issue?

Here’s the similar error I receive but we’ve only noticed it so far after a web socket connection is make (we use socket.io, not LiveQuery. “Connected Org” indicates the socket connected, but when a socket packet is sent the issue appears):

Feb 13 19:07:50 ip-172-31-46-111 web: ** Connected Org ** org-msuCCi5FKB47k4Q-hmWs78wB
Feb 13 19:07:50 ip-172-31-46-111 web: event getK12 { action_id: 1 }
Feb 13 19:07:50 ip-172-31-46-111 web: error: Error creating a file: option enableschemahooks is not supported {“stack”:“MongoParseError: option enableschemahooks is not supported\n at parseOptions (/var/app/current/node_modules/mongodb/lib/connection_string.js:290:15)\n at new MongoClient (/var/app/current/node_modules/mongodb/lib/mongo_client.js:44:63)\n at Function.connect (/var/app/current/node_modules/mongodb/lib/mongo_client.js:213:33)\n at GridFSBucketAdapter._connect (/var/app/current/node_modules/parse-server/lib/Adapters/Files/GridFSBucketAdapter.js:41:54)\n at GridFSBucketAdapter._getBucket (/var/app/current/node_modules/parse-server/lib/Adapters/Files/GridFSBucketAdapter.js:51:17)\n at GridFSBucketAdapter.createFile (/var/app/current/node_modules/parse-server/lib/Adapters/Files/GridFSBucketAdapter.js:57:31)\n at FilesController.createFile (/var/app/current/node_modules/parse-server/lib/Controllers/FilesController.js:46:25)\n at createHandler (/var/app/current/node_modules/parse-server/lib/Routers/FilesRouter.js:223:56)\n at runMicrotasks ()\n at processTicksAndRejections (internal/process/task_queues.js:93:5)”}
Feb 13 19:07:50 ip-172-31-46-111 web: error: option enableschemahooks is not supported {“code”:130,“stack”:“MongoParseError: option enableschemahooks is not supported\n at parseOptions (/var/app/current/node_modules/mongodb/lib/connection_string.js:290:15)\n at new MongoClient (/var/app/current/node_modules/mongodb/lib/mongo_client.js:44:63)\n at Function.connect (/var/app/current/node_modules/mongodb/lib/mongo_client.js:213:33)\n at GridFSBucketAdapter._connect (/var/app/current/node_modules/parse-server/lib/Adapters/Files/GridFSBucketAdapter.js:41:54)\n at GridFSBucketAdapter._getBucket (/var/app/current/node_modules/parse-server/lib/Adapters/Files/GridFSBucketAdapter.js:51:17)\n at GridFSBucketAdapter.createFile (/var/app/current/node_modules/parse-server/lib/Adapters/Files/GridFSBucketAdapter.js:57:31)\n at FilesController.createFile (/var/app/current/node_modules/parse-server/lib/Controllers/FilesController.js:46:25)\n at createHandler (/var/app/current/node_modules/parse-server/lib/Routers/FilesRouter.js:223:56)\n at runMicrotasks ()\n at processTicksAndRejections (internal/process/task_queues.js:93:5)”}

It appears that it might be a MongoDB issue for us but I’m still looking into it.

#5

No, we did not solve it yet. We have to look into it. My gut feeling is that our CI environment has a different config.