Latest changes breaking rest api and core views on parse.com due to addition of _PushStatus in _SCHEMA

[alanphoon]

Background: We are slowly migrating over to parse-server from parse.com. Current implementation is mongoDB migrated to mLab with both parse-server and parse.com running on the same mLab DB instance. We need to be able to run both in parallel.

Issue: Recent code changes in parse-server is causing issues with parse.com, particularly with pushes through rest api and even trying to view core collections on parse.com dashboard. The following error message is thrown:

{"code":103,"error":"Invalid classname: _PushStatus, classnames can only have alphanumeric characters and _, and must start with an alpha character "}

Cause: This occurred after updating parse-server with latest commits and then sending a push notification through parse-server. From what I found, parse-server is adding the following entry to the _SCHEMA collection:

{
    "_id": "_PushStatus",
    ...
    "failedPerType": "object"
}

While this works fine for parse-server, this is causing parse.com to completely break. Removing _PushStatus entry from _SCHEMA fixes this and parse.com dashboard and API works.

[flovilmart]

@alanphoon can you please post the logs that happen on parse-server when parse.com is trying to send the push to it when running with VERBOSE=1?

[drew-gross]

This is parse.com breaking, not Parse Server. We should either revert that PR, or hold off on releasing 2.2.8 until we have a better solution. Maybe we can use a different collection name for the new system schemas, so Parse.com doesn't see them, but Parse Server does.

[alanphoon]

@flovilmart As per @drew-gross comments, no logs as parse.com is breaking not parse-server. Let me know if you guys need anything else. Thanks.

[flovilmart]

oh shit.... so remove the _PushStatus from the reserved classes? We can also skip Schema creation for _PushStatus as it's internal, protected by master key...

[drew-gross]

I say keep it in reserved classes and either have the mongoAdapter have a check and not create anything that isn't one of the known special classes, or have it create it in a different collection. I do think the ideal behaviour is to have _PushStatus be a Parse Object, so if we can move towards that being true while also not breaking Parse.com that would be sweet.

[flovilmart]

yeah, I'd skip the creation altogether, but not in the adapter, as the problem may surface with other adapters.

[drew-gross]

Other adapters probably wouldn't be used if you are still using Parse.com. Once we extract the current adapter we can call it LegacyMongoAdapter and have it do all sorts of crazy shit to be compatible with Parse.com, and recommend new projects use MongoAdapter which will actually be consistent and do things that make sense (if it ever exists...)

[flovilmart]

uhm ok, I'll check it out

[flovilmart]

fixed by #1636

[grd888]

If I understand it right, this issue should not be present anymore in current version 2.2.16 , correct ? However I am seeing this in my AWS EB deployment. Once a push is sent from parse-server, _PushStatus appears in the _SCHEMA collection and dashboard.parse.com breaks with:

{"code":103,"error":"Invalid classname: _PushStatus, classnames can only have alphanumeric characters and _, and must start with an alpha character "}

Also, pushes from parse.com do not go through anymore, while pushes from parse-server are ok. After removing the _PushStatus document from the _SCHEMA collection, the problem goes away and pushes from parse.com succeed once more, until another push is sent from parse-server.

This is the only thing now holding us back from fully migrating to parse-server.

[sprabs]

@grd888 @flovilmart I'm hitting the same problem and it is also the last thing holding us back from fully migrating. Did you end up finding a solution???

[grd888]

@sprabs I ended up rolling back to 2.2.7, which does not exhibit this issue. Once I get sufficiently enough clients upgrade their mobile apps to the version that uses parse-server, that's the time I will consider moving parse-server to the latest versions.

[flovilmart]

If you use parse-dashboard, is it all ok?

[sprabs]

@flovilmart: I mean, the bigger issue is that push notifications fail when sent from any clients (via cloud code) still using parse.com (which would be a number of clients in the month or so that our users transition via force update). This issue makes parse-server clients incompatible with parse.com clients. That's bad.

[sprabs]

Copying my comment from #2275

@flovilmart I checked the commit you added to fix the issue in April. I noticed that in the latest code, part of that was lost. I have done a point fix on my side and am still testing. It's just a single line in src/Controllers/DatabaseController.js from: #1636

Would incorporating that change back in solve the _PushStatus problem or does more need to be done?