_PushStatus issue after upgrade to 3.1.x #5161

fxchou123 · 2018-11-01T21:57:57Z

error: Uncaught internal server error. TypeError: Cannot redefine property: _PushStatus
at Function.defineProperty ()
at SchemaData.volatileClasses.forEach.className (/app/node_modules/parse-server/lib/Controllers/SchemaController.js:530:14)
at Array.forEach ()
at new SchemaData (/app/node_modules/parse-server/lib/Controllers/SchemaController.js:529:21)
at getAllClasses.then.allSchemas (/app/node_modules/parse-server/lib/Controllers/SchemaController.js:654:27)
at process.internalTickCallback (internal/process/next_tick.js:77:7) TypeError: Cannot redefine property: _PushStatus
at Function.defineProperty ()
at SchemaData.volatileClasses.forEach.className (/app/node_modules/parse-server/lib/Controllers/SchemaController.js:530:14)
at Array.forEach ()
at new SchemaData (/app/node_modules/parse-server/lib/Controllers/SchemaController.js:529:21)
at getAllClasses.then.allSchemas (/app/node_modules/parse-server/lib/Controllers/SchemaController.js:654:27)
at process.internalTickCallback (internal/process/next_tick.js:77:7)
TypeError: Cannot redefine property: _PushStatus
at Function.defineProperty ()
at SchemaData.volatileClasses.forEach.className (/app/node_modules/parse-server/lib/Controllers/SchemaController.js:530:14)
at Array.forEach ()
at new SchemaData (/app/node_modules/parse-server/lib/Controllers/SchemaController.js:529:21)
at getAllClasses.then.allSchemas (/app/node_modules/parse-server/lib/Controllers/SchemaController.js:654:27)
at process.internalTickCallback (internal/process/next_tick.js:77:7)

flovilmart · 2018-11-01T22:14:27Z

Do you happen to have by any chance an _PushStatus object in your _SCHEMA table?

fxchou123 · 2018-11-02T04:54:32Z

Do you happen to have by any chance an _PushStatus object in your _SCHEMA table?

Yes I do. Parse Server automatically generated this object in version 3.0

Should I delete it instead?

fxchou123 · 2018-11-02T05:00:21Z

Do you happen to have by any chance an _PushStatus object in your _SCHEMA table?

I tried to delete this object and got another error instead.

warn: Unable to ensure uniqueness for user email addresses: MongoError: Index with name: email_1 already exists with different options
at /app/node_modules/mongodb-core/lib/connection/pool.js:581:63
at authenticateStragglers (/app/node_modules/mongodb-core/lib/connection/pool.js:504:16)
at Connection.messageHandler (/app/node_modules/mongodb-core/lib/connection/pool.js:540:5)
at emitMessageHandler (/app/node_modules/mongodb-core/lib/connection/connection.js:310:10)
at Socket. (/app/node_modules/mongodb-core/lib/connection/connection.js:489:15)
at Socket.emit (events.js:182:13)
at Socket.EventEmitter.emit (domain.js:441:20)
at addChunk (_stream_readable.js:283:12)
at readableAddChunk (_stream_readable.js:264:11)
at Socket.Readable.push (_stream_readable.js:219:10)

flovilmart · 2018-11-02T11:49:58Z

What version were you running before upgrading to 3.1? The alert you’re seeing is regarding the _User table.

fxchou123 · 2018-11-02T20:47:00Z

What version were you running before upgrading to 3.1? The alert you’re seeing is regarding the _User table.

From 3.0.0

Everything works fine in version 3.0.0

nebitrams · 2018-11-07T23:47:27Z

I am running parse-server 3.1.0 and also see similar warning when I start up parse-server (npm start).

Warnings on 3 index:

email_1
username_1
name_1

Is there any need to re-create the index on _User table when upgrading to 3.1.0?

warn: Unable to ensure uniqueness for user email addresses: MongoError: Index with name: email_1 already exists with different options
at /Users/Nebi/Documents/heroku/xxx/node_modules/mongodb-core/lib/connection/pool.js:581:63
at authenticateStragglers (/Users/Nebi/Documents/heroku/xxx/node_modules/mongodb-core/lib/connection/pool.js:504:16)
at Connection.messageHandler (/Users/Nebi/Documents/heroku/xxx/node_modules/mongodb-core/lib/connection/pool.js:540:5)
at emitMessageHandler (/Users/Nebi/Documents/heroku/xxx/node_modules/mongodb-core/lib/connection/connection.js:310:10)
at Socket. (/Users/Nebi/Documents/heroku/xxx/node_modules/mongodb-core/lib/connection/connection.js:453:17)
at Socket.emit (events.js:182:13)
at Socket.EventEmitter.emit (domain.js:442:20)
at addChunk (_stream_readable.js:283:12)
at readableAddChunk (_stream_readable.js:264:11)
at Socket.Readable.push (_stream_readable.js:219:10)
(node:86452) UnhandledPromiseRejectionWarning: MongoError: Index with name: email_1 already exists with different options
at /Users/Nebi/Documents/heroku/xxx/node_modules/mongodb-core/lib/connection/pool.js:581:63
at authenticateStragglers (/Users/Nebi/Documents/heroku/xxx/node_modules/mongodb-core/lib/connection/pool.js:504:16)
at Connection.messageHandler (/Users/Nebi/Documents/heroku/xxx/node_modules/mongodb-core/lib/connection/pool.js:540:5)
at emitMessageHandler (/Users/Nebi/Documents/heroku/xxx/node_modules/mongodb-core/lib/connection/connection.js:310:10)
at Socket. (/Users/Nebi/Documents/heroku/xxx/node_modules/mongodb-core/lib/connection/connection.js:453:17)
at Socket.emit (events.js:182:13)
at Socket.EventEmitter.emit (domain.js:442:20)
at addChunk (_stream_readable.js:283:12)
at readableAddChunk (_stream_readable.js:264:11)
at Socket.Readable.push (_stream_readable.js:219:10)
(node:86452) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). (rejection id: 1)
(node:86452) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.
warn: Unable to ensure uniqueness for usernames: MongoError: Index with name: username_1 already exists with different options
at /Users/Nebi/Documents/heroku/xxx/node_modules/mongodb-core/lib/connection/pool.js:581:63
at authenticateStragglers (/Users/Nebi/Documents/heroku/xxx/node_modules/mongodb-core/lib/connection/pool.js:504:16)
at Connection.messageHandler (/Users/Nebi/Documents/heroku/xxx/node_modules/mongodb-core/lib/connection/pool.js:540:5)
at emitMessageHandler (/Users/Nebi/Documents/heroku/xxx/node_modules/mongodb-core/lib/connection/connection.js:310:10)
at Socket. (/Users/Nebi/Documents/heroku/xxx/node_modules/mongodb-core/lib/connection/connection.js:489:15)
at Socket.emit (events.js:182:13)
at Socket.EventEmitter.emit (domain.js:442:20)
at addChunk (_stream_readable.js:283:12)
at readableAddChunk (_stream_readable.js:264:11)
at Socket.Readable.push (_stream_readable.js:219:10)
warn: Unable to ensure uniqueness for role name: MongoError: Index with name: name_1 already exists with different options
at /Users/Nebi/Documents/heroku/xxx/node_modules/mongodb-core/lib/connection/pool.js:581:63
at authenticateStragglers (/Users/Nebi/Documents/heroku/xxx/node_modules/mongodb-core/lib/connection/pool.js:504:16)
at Connection.messageHandler (/Users/Nebi/Documents/heroku/xxx/node_modules/mongodb-core/lib/connection/pool.js:540:5)
at emitMessageHandler (/Users/Nebi/Documents/heroku/xxx/node_modules/mongodb-core/lib/connection/connection.js:310:10)
at Socket. (/Users/Nebi/Documents/heroku/xxx/node_modules/mongodb-core/lib/connection/connection.js:489:15)
at Socket.emit (events.js:182:13)
at Socket.EventEmitter.emit (domain.js:442:20)
at addChunk (_stream_readable.js:283:12)
at readableAddChunk (_stream_readable.js:264:11)
at Socket.Readable.push (_stream_readable.js:219:10)

flovilmart · 2018-11-07T23:57:46Z

Are you able to provide the indexes from mongo perspective? We may have inadvertently mis implemented a feature in 3.1

nebitrams · 2018-11-08T00:21:32Z

@flovilmart, I believe these are the 3 indices. First two on _User and the last one on _Role.

{
"v": 1,
"key": {
"email": 1
},
"name": "email_1",
"ns": "xxx._User",
"background": true
}

{
"v": 1,
"key": {
"username": 1
},
"name": "username_1",
"ns": "xxx._User",
"background": true
}

{
"v": 1,
"unique": true,
"key": {
"name": 1
},
"name": "name_1",
"ns": "xxx._Role"
}

nebitrams · 2018-11-08T00:22:38Z

According this this thread, you might have added unique constraints in 3.1.0.

https://stackoverflow.com/questions/30232081/mongoexception-index-with-name-code-already-exists-with-different-options/30232270

flovilmart · 2018-11-08T00:24:37Z

Would you be able to start a parse-server on a clean DB, and tell me what what do the indexes look like?

nebitrams · 2018-11-08T00:28:01Z

I have migrated my DB from parse.com since 2 years ago. I didn't know how to start from a clean DB. Could you point me to some documentation on this? I will try again about 12 hours from now. :-)

flovilmart · 2018-11-08T00:47:56Z

Just start a local mongo database. Look into the starting guides on the http://docs.parseplatform.org website

johanarnor · 2018-11-08T15:23:25Z

Might have a solution to this. We got the same error: Unable to ensure uniqueness for role name: MongoError: Index with name: name_1 already exists with different options when trying to start with our old DB from parse.com with parse-server 3.1.1.

The issue was that we had an index { "name": 1 } on _Role, but with sparse set to false. So we just deleted the index and parse-server created a new one (the same index, but with sparse set to true on start up.

nebitrams · 2018-11-08T22:54:03Z

I created a blank local database and started parse server connecting to the local database. It automatically creates the _User, _SCHEMA, _Role with indexes. This is the mongod log with schema and indexes details.

2018-11-09T06:35:53.161+0800 I COMMAND  [conn3327] command parse._SCHEMA command: insert { insert: "_SCHEMA", documents: [ { _id: "_User", objectId: "string", updatedAt: "date", createdAt: "date", username: "string", email: "string", emailVerified: "boolean", authData: "object" } ], ordered: true } ninserted:1 keyUpdates:0 writeConflicts:0 numYields:0 reslen:40 locks:{ Global: { acquireCount: { r: 2, w: 2 } }, Database: { acquireCount: { w: 1, W: 1 } }, Collection: { acquireCount: { W: 1 } } } protocol:op_query 124ms
2018-11-09T06:35:53.166+0800 I COMMAND  [conn3329] command parse._Hooks command: find { find: "_Hooks", filter: {}, sort: {}, projection: {}, returnKey: false, showRecordId: false } planSummary: EOF keysExamined:0 docsExamined:0 cursorExhausted:1 keyUpdates:0 writeConflicts:0 numYields:0 nreturned:0 reslen:118 locks:{ Global: { acquireCount: { r: 2 } }, Database: { acquireCount: { r: 1 }, acquireWaitCount: { r: 1 }, timeAcquiringMicros: { r: 109172 } }, Collection: { acquireCount: { r: 1 } } } protocol:op_query 109ms
2018-11-09T06:35:53.209+0800 I COMMAND  [conn3328] command parse._SCHEMA command: insert { insert: "_SCHEMA", documents: [ { _id: "_Role", objectId: "string", updatedAt: "date", createdAt: "date", name: "string", users: "relation<_User>", roles: "relation<_Role>" } ], ordered: true } ninserted:1 keyUpdates:0 writeConflicts:0 numYields:0 reslen:40 locks:{ Global: { acquireCount: { r: 1, w: 1 } }, Database: { acquireCount: { w: 1 }, acquireWaitCount: { w: 1 }, timeAcquiringMicros: { w: 121407 } }, Collection: { acquireCount: { w: 1 } } } protocol:op_query 173ms
2018-11-09T06:35:53.339+0800 I INDEX    [conn3329] build index on: parse._User properties: { v: 1, unique: true, key: { username: 1 }, name: "username_1", ns: "parse._User", background: true, sparse: true }
2018-11-09T06:35:53.389+0800 I INDEX    [conn3327] build index on: parse._User properties: { v: 1, unique: true, key: { email: 1 }, name: "email_1", ns: "parse._User", background: true, sparse: true }
2018-11-09T06:35:53.389+0800 I INDEX    [conn3329] build index done.  scanned 0 total records. 0 secs
2018-11-09T06:35:53.389+0800 I INDEX    [conn3327] build index done.  scanned 0 total records. 0 secs
2018-11-09T06:35:53.401+0800 I COMMAND  [conn3328] command parse._SCHEMA command: find { find: "_SCHEMA", filter: {}, returnKey: false, showRecordId: false } planSummary: COLLSCAN keysExamined:0 docsExamined:2 cursorExhausted:1 keyUpdates:0 writeConflicts:0 numYields:0 nreturned:2 reslen:445 locks:{ Global: { acquireCount: { r: 2 } }, Database: { acquireCount: { r: 1 }, acquireWaitCount: { r: 1 }, timeAcquiringMicros: { r: 176282 } }, Collection: { acquireCount: { r: 1 } } } protocol:op_query 188ms
2018-11-09T06:35:53.403+0800 I COMMAND  [conn3329] command parse.$cmd command: createIndexes { createIndexes: "_User", indexes: [ { name: "username_1", key: { username: 1 }, unique: true, background: true, sparse: true } ] } keyUpdates:0 writeConflicts:0 numYields:0 reslen:113 locks:{ Global: { acquireCount: { r: 1, w: 1 } }, Database: { acquireCount: { w: 1, W: 2 }, acquireWaitCount: { w: 1, W: 2 }, timeAcquiringMicros: { w: 48296, W: 48466 } }, Collection: { acquireCount: { w: 1 } } } protocol:op_query 231ms
2018-11-09T06:35:53.406+0800 I COMMAND  [conn3327] command parse.$cmd command: createIndexes { createIndexes: "_User", indexes: [ { name: "email_1", key: { email: 1 }, unique: true, background: true, sparse: true } ] } keyUpdates:0 writeConflicts:0 numYields:0 reslen:113 locks:{ Global: { acquireCount: { r: 1, w: 1 } }, Database: { acquireCount: { w: 1, W: 2 }, acquireWaitCount: { W: 2 }, timeAcquiringMicros: { W: 182237 } }, Collection: { acquireCount: { w: 1 } } } protocol:op_query 235ms
2018-11-09T06:35:53.584+0800 I INDEX    [conn3328] build index on: parse._Role properties: { v: 1, unique: true, key: { name: 1 }, name: "name_1", ns: "parse._Role", background: true, sparse: true }
2018-11-09T06:35:53.584+0800 I INDEX    [conn3328] build index done.  scanned 0 total records. 0 secs
2018-11-09T06:35:53.587+0800 I COMMAND  [conn3328] command parse.$cmd command: createIndexes { createIndexes: "_Role", indexes: [ { name: "name_1", key: { name: 1 }, unique: true, background: true, sparse: true } ] } keyUpdates:0 writeConflicts:0 numYields:0 reslen:113 locks:{ Global: { acquireCount: { r: 1, w: 1 } }, Database: { acquireCount: { w: 1, W: 2 }, acquireWaitCount: { W: 1 }, timeAcquiringMicros: { W: 1817 } }, Collection: { acquireCount: { w: 1 } } } protocol:op_query 179ms

flovilmart · 2018-11-08T23:10:50Z

Ok so the main issue is that now we create the indexes as unique + sparse, as you initially envisioned. Now I am not sure of the best resolution:

ignore the warning
delete and replace the index
create the new index under a different name (and then perhaps delete the existing one)

What do you think?

nebitrams · 2018-11-08T23:35:06Z

Is "sparse" is used when a field could be left as "undefined". Are these 3 fields optional?

If the "sparse" is required, I suggest to delete and replace the index upon parse-server start up. Does parse-server has sufficient right to drop index? We should not leave unused Index because indices took up precious disk space and cpu time.

flovilmart · 2018-11-08T23:37:22Z

Yeah, they do, temporarily, we could create the new one and replace the old one.

Is it something you’d like to implement?

nebitrams · 2018-11-09T00:35:54Z

The best way to give back when you receive a favour is to contribute code :-) However, I am not so sure at the moment. Let's me explore a bit further on parse-server codebase.

flovilmart · 2018-11-09T00:40:34Z

There is a workaround, and the setup is not completely broken. You could destroy your indexes and restart the server this would ‘just work’. But not as clean as doing a migration.

And as a long time user (as you said), it’s always good to have his hand dirty :)

nebitrams · 2018-11-25T02:06:45Z

It works.

I have dropped these indices and then new indices automatically created in next parse-server restart.

_User.email_1
_User.username_1
_Role.name_1

Recreated index on _User
{
"v": 2,
"unique": true,
"key": {
"email": 1
},
"name": "email_1",
"ns": "xxx._User",
"background": true,
"sparse": true
}

{
"v": 2,
"unique": true,
"key": {
"username": 1
},
"name": "username_1",
"ns": "xxx._User",
"background": true,
"sparse": true
}

Recreated index on _Role
{
"v": 2,
"unique": true,
"key": {
"name": 1
},
"name": "name_1",
"ns": "xxx._Role",
"background": true,
"sparse": true
}

stale · 2019-01-09T04:56:18Z

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

jc73300 · 2019-02-03T18:55:54Z

I am a little late to this party and have just started upgrading from 3.0.0 to 3.1.x and have this issue. How do I go about fixing this issue?

flovilmart · 2019-02-03T19:33:43Z

@jc73300 did you try what @nebitrams suggested?

_{Sent with GitHawk}

jc73300 · 2019-02-03T19:37:51Z

I am unsure how to do what he suggested.

flovilmart · 2019-02-03T19:43:30Z

@jc73300 did you try asking google how to drop an index on MongoDB?

_{Sent with GitHawk}

flovilmart · 2019-02-03T20:22:47Z

You just need to delete the existing index, and restart the server, the new indexes will be created automatically. Alternatively, one could open a PR so we name the index so it lifts the conflict

_{Sent with GitHawk}

jc73300 · 2019-02-03T20:41:53Z

Maybe the issue is something else. I have verified the indices are what they should be according to nebitrams. Every time I try to deploy 3.1.0 I get the following in my logs. 2019-02-03T20:36:28.475Z - Uncaught internal server error. TypeError: Cannot redefine property: _PushStatus at Function.defineProperty (<anonymous>) at SchemaData.volatileClasses.forEach.className (/var/app/current/node_modules/parse-server/lib/Controllers/SchemaController.js:530:14) at Array.forEach (<anonymous>) at new SchemaData (/var/app/current/node_modules/parse-server/lib/Controllers/SchemaController.js:529:21) at getAllClasses.then.allSchemas (/var/app/current/node_modules/parse-server/lib/Controllers/SchemaController.js:654:27) at <anonymous> at process._tickDomainCallback (internal/process/next_tick.js:229:7) TypeError: Cannot redefine property: _PushStatus at Function.defineProperty (<anonymous>) at SchemaData.volatileClasses.forEach.className (/var/app/current/node_modules/parse-server/lib/Controllers/SchemaController.js:530:14) at Array.forEach (<anonymous>) at new SchemaData (/var/app/current/node_modules/parse-server/lib/Controllers/SchemaController.js:529:21) at getAllClasses.then.allSchemas (/var/app/current/node_modules/parse-server/lib/Controllers/SchemaController.js:654:27) at <anonymous> at process._tickDomainCallback (internal/process/next_tick.js:229:7) 2019-02-03T20:36:03.702Z - Unable to ensure uniqueness for role name: 2019-02-03T20:36:03.700Z - Unable to ensure uniqueness for usernames:

flovilmart · 2019-02-04T00:51:41Z

That’s the same error, unable to ensure uniqueness for role and username, which means that you have an exiting index which is not correct, and that the server attempts to create new ones. What are the indices for _Role and _User?

_{Sent with GitHawk}

flovilmart · 2019-02-04T01:22:24Z

what bugs me is that the version 3.0.0 is also creating sparse indexes and your indices look right in the DB.

Would you have access to the mongodb logs, or runinng VERBOSE=1 with the version 3.1.0 and provide the full logs?

jc73300 · 2019-02-04T01:29:47Z

I turned on verbose, what do you need?

flovilmart · 2019-02-04T01:31:16Z

The logs on startup

_{Sent with GitHawk}

jc73300 · 2019-02-04T01:47:35Z

Does this help?

2019-02-04T01:46:16.823Z - RESPONSE from [GET] /parse/serverInfo: {
"response": {
"features": {
"globalConfig": {
"create": true,
"read": true,
"update": true,
"delete": true
},
"hooks": {
"create": true,
"read": true,
"update": true,
"delete": true
},
"cloudCode": {
"jobs": true
},
"logs": {
"level": true,
"size": true,
"order": true,
"until": true,
"from": true
},
"push": {
"immediatePush": true,
"scheduledPush": false,
"storedPushData": true,
"pushAudiences": true,
"localization": true
},
"schemas": {
"addField": true,
"removeField": true,
"addClass": true,
"removeClass": true,
"clearAllDataFromClass": true,
"exportClass": false,
"editClassLevelPermissions": true,
"editPointerPermissions": true
}
},
"parseServerVersion": "3.1.0"
}
}
2019-02-04T01:46:16.812Z - REQUEST for [GET] /parse/serverInfo: {}
2019-02-04T01:45:55.501Z - Unable to ensure uniqueness for role name:
2019-02-04T01:45:55.498Z - Unable to ensure uniqueness for usernames:

jc73300 · 2019-02-04T01:50:18Z

Stupid question, can I just copy _Installations and any of my own tables to a new clean db or will it break everything?

flovilmart · 2019-02-04T01:57:22Z

What I am looking for is the actual error. As for why the index creation failed. Can you check the MongoDB logs?

_{Sent with GitHawk}

jc73300 · 2019-02-04T01:59:26Z

I don't have access to them.

flovilmart · 2019-02-04T02:08:07Z

Well, that’s problematic. I’m not sure I can be of further help. Without the exact error, I am not sure what can be done

_{Sent with GitHawk}

jc73300 · 2019-02-04T02:09:44Z

Ok no worries. I will just live on 3.0.0 until it dies.

flovilmart · 2019-02-04T02:12:57Z

There should be additional info when you start your server locally with 3.1.0

For example:

warn: Unable to ensure uniqueness for usernames:  MongoError: Index with name: username_1 already exists with different options
    at /Users/florent/src/Parse/parse-server/node_modules/mongodb-core/lib/connection/pool.js:581:63
    at authenticateStragglers (/Users/florent/src/Parse/parse-server/node_modules/mongodb-core/lib/connection/pool.js:504:16)
    at Connection.messageHandler (/Users/florent/src/Parse/parse-server/node_modules/mongodb-core/lib/connection/pool.js:540:5)
    at emitMessageHandler (/Users/florent/src/Parse/parse-server/node_modules/mongodb-core/lib/connection/connection.js:310:10)
    at Socket.<anonymous> (/Users/florent/src/Parse/parse-server/node_modules/mongodb-core/lib/connection/connection.js:453:17)
    at Socket.emit (events.js:182:13)
    at Socket.EventEmitter.emit (domain.js:441:20)
    at addChunk (_stream_readable.js:283:12)
    at readableAddChunk (_stream_readable.js:264:11)
    at Socket.Readable.push (_stream_readable.js:219:10)
(node:28426) UnhandledPromiseRejectionWarning: MongoError: Index with name: username_1 already exists with different options
    at /Users/florent/src/Parse/parse-server/node_modules/mongodb-core/lib/connection/pool.js:581:63
    at authenticateStragglers (/Users/florent/src/Parse/parse-server/node_modules/mongodb-core/lib/connection/pool.js:504:16)
    at Connection.messageHandler (/Users/florent/src/Parse/parse-server/node_modules/mongodb-core/lib/connection/pool.js:540:5)
    at emitMessageHandler (/Users/florent/src/Parse/parse-server/node_modules/mongodb-core/lib/connection/connection.js:310:10)
    at Socket.<anonymous> (/Users/florent/src/Parse/parse-server/node_modules/mongodb-core/lib/connection/connection.js:453:17)
    at Socket.emit (events.js:182:13)
    at Socket.EventEmitter.emit (domain.js:441:20)
    at addChunk (_stream_readable.js:283:12)
    at readableAddChunk (_stream_readable.js:264:11)
    at Socket.Readable.push (_stream_readable.js:219:10)

don't you have those?

Ok no worries. I will just live on 3.0.0 until it dies.

I'm not sure why I spent a good amount of my sunday evening trying to help you then.

jc73300 · 2019-02-04T02:16:39Z

I definitely appreciate the help you gave me I just don't know what else to do and since I cannot give you the logs you requested there isn't much else that can be done.

flovilmart · 2019-02-04T02:29:14Z

But for one, what is the error that goes after unable to ensure uniqueness for usernames:

_{Sent with GitHawk}

jc73300 · 2019-02-05T05:35:49Z

Just wanted to let you know @flovilmart . I ended up exporting the relevant tables with data into a new clean db and all is working great now. I updated all the way to the current 3.1.3. Thanks again for all your help.

jdlugo · 2019-02-09T18:37:59Z

@flovilmart I believe I had a similar problem to @jc73300. I tested all parse-server versions greater than 3.0.0 and consistently ran into this problem. I do not experience this problem with 3.0.0. I am using Postgres, for what it's worth.

2019-02-09T18:33:48.106800+00:00 app[web.1]: TypeError: Cannot redefine property: _Installation
2019-02-09T18:33:48.106803+00:00 app[web.1]: at Function.defineProperty ()
2019-02-09T18:33:48.106805+00:00 app[web.1]: at SchemaData.allSchemas.forEach.schema (/app/node_modules/parse-server/lib/Controllers/SchemaController.js:514:14)
2019-02-09T18:33:48.106806+00:00 app[web.1]: at Array.forEach ()
2019-02-09T18:33:48.106808+00:00 app[web.1]: at new SchemaData (/app/node_modules/parse-server/lib/Controllers/SchemaController.js:513:16)
2019-02-09T18:33:48.106810+00:00 app[web.1]: at getAllClasses.then.allSchemas (/app/node_modules/parse-server/lib/Controllers/SchemaController.js:654:27)
2019-02-09T18:33:48.106811+00:00 app[web.1]: at processTicksAndRejections (internal/process/next_tick.js:81:5)

flovilmart · 2019-02-09T18:41:57Z

Can you share your schema please?

_{Sent with GitHawk}

flovilmart · 2019-02-09T18:51:31Z

It’s not what I meant, I meant the contents of the _SCHEMA table

_{Sent with GitHawk}

jdlugo · 2019-02-09T18:59:55Z

create table "_SCHEMA"
(
"className" varchar(120) default NULL::character varying not null,
schema jsonb,
"isParseClass" boolean
);

INSERT INTO public."_SCHEMA" ("className", schema) VALUES ('_Installation', '{"fields": {"id": {"type": "String"}, "user": {"type": "Pointer", "targetClass": "_User"}, "badge": {"type": "Number"}, "_rperm": {"type": "Array", "contents": {"type": "String"}}, "_wperm": {"type": "Array", "contents": {"type": "String"}}, "appName": {"type": "String"}, "channels": {"type": "Array"}, "objectId": {"type": "String"}, "pushType": {"type": "String"}, "timeZone": {"type": "String"}, "createdAt": {"type": "Date"}, "updatedAt": {"type": "Date"}, "appVersion": {"type": "String"}, "deviceType": {"type": "String"}, "GCMSenderId": {"type": "String"}, "deviceToken": {"type": "String"}, "parseVersion": {"type": "String"}, "appIdentifier": {"type": "String"}, "installationId": {"type": "String"}, "localeIdentifier": {"type": "String"}}, "className": "_Installation"}');

flovilmart · 2019-02-09T19:52:17Z

Ok. I believe I know what’s going on, but I am not sure how the _Installation schema is appearing twice. Would you be able to insert a console.log to print the contents of the allClasses array?

_{Sent with GitHawk}

acegreen · 2019-02-19T12:25:07Z

Might have a solution to this. We got the same error: Unable to ensure uniqueness for role name: MongoError: Index with name: name_1 already exists with different options when trying to start with our old DB from parse.com with parse-server 3.1.1.

The issue was that we had an index { "name": 1 } on _Role, but with sparse set to false. So we just deleted the index and parse-server created a new one (the same index, but with sparse set to true on start up.

@johanarnor Does dropping the index delete the contents in that column? I need the usernames & emails of _User

johanarnor · 2019-02-19T14:27:07Z

@acegreen Nope, the data stays safe, we just deleted the index in mongodb. We're using mLab, so it was just a few clicks in the GUI. I guess they run dropIndex.

acegreen · 2019-02-21T14:05:09Z

I was able to dropIndexes for _Role name and _User username but dropping _User email doesn't resolve the last warning I have

nebitrams · 2019-02-21T23:05:57Z

@acegreen
What is the last warning that you mentioned?

For me, 3 warnings of these nature were gone.

warn: Unable to ensure uniqueness for usernames: MongoError: Index with name: username_1 already exists with different options

acegreen · 2019-02-22T02:06:17Z

exactly those, the last one was the email which i dropped as well but the warning won't go away. For some reason my warning is truncated so I don't actually see the index name

stoodkev · 2019-04-29T08:05:24Z

@acegreen I have the same issue, did you solve it?

grassland-curing-cfa · 2019-11-18T01:07:21Z

I have had the same issue.
Thanks to @johanarnor advice, it was finally fixed after I manually drop indices "email_1" and "username_1" on the _User table and "name_1" on the _Role table. Check the log and identify those indices that threw errors and then drop them. I did it from MongoDB Atlas web console.
I am with a couple of MongoDB database recently migrated from mLab to MongoDB Atlas due to mandatory migration requirement. Those indices were created during the migration process but they failed deployment of Parse-server on version 3.9.0 (latest as of today). It was fine with 2.8.4 before migrating.

grassland-curing-cfa · 2019-11-18T01:11:23Z

exactly those, the last one was the email which i dropped as well but the warning won't go away. For some reason my warning is truncated so I don't actually see the index name

@acegreen I did dropIndex on those ones that threw errors from the log. Then re-deployed Parse-server the warnings were gone. I am with MongoDB 4.0.0 on MongoDB Atlas and Parse-server 3.9.0.

Skyb0rg · 2020-02-12T20:31:35Z

run into the same issues:

Resolve this with Mongo Shell

db.getCollection("_User").dropIndex("email_1")
db.getCollection("_User").dropIndex("username_1")
db.getCollection("_Role").dropIndex("name_1")

stale bot added the wontfix label Jan 9, 2019

stale bot closed this as completed Jan 16, 2019

nebitrams mentioned this issue Feb 18, 2019

Updating from v2.3.6 to v3.1.3 MongoDB access issue #5372

Closed

This was referenced May 21, 2023

refactor: Upgrade @graphql-tools/merge from 8.3.6 to 8.4.1 #8544

Merged

refactor: Upgrade @graphql-tools/merge from 8.3.17 to 8.4.1 #8555

Merged

_PushStatus issue after upgrade to 3.1.x #5161

_PushStatus issue after upgrade to 3.1.x #5161

Comments

fxchou123 commented Nov 1, 2018 • edited Loading

flovilmart commented Nov 1, 2018

fxchou123 commented Nov 2, 2018

fxchou123 commented Nov 2, 2018

flovilmart commented Nov 2, 2018

fxchou123 commented Nov 2, 2018 • edited Loading

nebitrams commented Nov 7, 2018

flovilmart commented Nov 7, 2018

nebitrams commented Nov 8, 2018

nebitrams commented Nov 8, 2018

flovilmart commented Nov 8, 2018

nebitrams commented Nov 8, 2018

flovilmart commented Nov 8, 2018

johanarnor commented Nov 8, 2018

nebitrams commented Nov 8, 2018

flovilmart commented Nov 8, 2018

nebitrams commented Nov 8, 2018 • edited Loading

flovilmart commented Nov 8, 2018

nebitrams commented Nov 9, 2018

flovilmart commented Nov 9, 2018

nebitrams commented Nov 25, 2018

stale bot commented Jan 9, 2019

jc73300 commented Feb 3, 2019

flovilmart commented Feb 3, 2019

jc73300 commented Feb 3, 2019

flovilmart commented Feb 3, 2019

flovilmart commented Feb 3, 2019

jc73300 commented Feb 3, 2019 via email • edited Loading

flovilmart commented Feb 4, 2019

flovilmart commented Feb 4, 2019

jc73300 commented Feb 4, 2019

flovilmart commented Feb 4, 2019

jc73300 commented Feb 4, 2019

jc73300 commented Feb 4, 2019

flovilmart commented Feb 4, 2019

jc73300 commented Feb 4, 2019

flovilmart commented Feb 4, 2019

jc73300 commented Feb 4, 2019

flovilmart commented Feb 4, 2019

jc73300 commented Feb 4, 2019

flovilmart commented Feb 4, 2019

jc73300 commented Feb 5, 2019

jdlugo commented Feb 9, 2019

flovilmart commented Feb 9, 2019

flovilmart commented Feb 9, 2019

jdlugo commented Feb 9, 2019

flovilmart commented Feb 9, 2019

acegreen commented Feb 19, 2019 • edited Loading

johanarnor commented Feb 19, 2019

acegreen commented Feb 21, 2019

nebitrams commented Feb 21, 2019

acegreen commented Feb 22, 2019

stoodkev commented Apr 29, 2019

grassland-curing-cfa commented Nov 18, 2019 • edited Loading

grassland-curing-cfa commented Nov 18, 2019

Skyb0rg commented Feb 12, 2020

fxchou123 commented Nov 1, 2018 •

edited

Loading

fxchou123 commented Nov 2, 2018 •

edited

Loading

nebitrams commented Nov 8, 2018 •

edited

Loading

jc73300 commented Feb 3, 2019 via email •

edited

Loading

acegreen commented Feb 19, 2019 •

edited

Loading

grassland-curing-cfa commented Nov 18, 2019 •

edited

Loading