Live Queries Server: wrong event returned when multiple subscription triggered

[percypyan]

New Issue Checklist

• I am not disclosing a vulnerability.
• I am not just asking a question.
• I have searched through existing issues.
• I can reproduce the issue with the latest version of Parse Server.

Issue Description

Since #7097, when two subscriptions on a collection are triggered simultaneously by a change but with different events (e.g. leave for the first and enter for the second), the same event is returned to the two web socket clients.
This is because of the combinaison of the forEach at ParseLiveQueryServer.js#L240 and the message.event = ... at ParseLiveQueryServer.js#L301.

message.event = ... is an update of the argument and cause issues because it's used in the asynchronous forEach. When the message.event is updated in one of the forEach loop run, it is updated for all. So when the function name is computed at ParseLiveQueryServer.js#L338, the last event attributed is used.

We should use res.event instead of message.event: this way we avoid updating a function argument and we ensure that the right event is triggered.

Steps to reproduce

Create a client with 2 subscriptions on the same collection:

1. const sub1 = await Parse.Query("MyCollection").equalTo("myBoolean", true).subscribe()
2. const sub2 = await Parse.Query("MyCollection").equalTo("myBoolean", false).subscribe()

Change an object by updating field myBoolean from true to false (or in the other way).

You'll see that on the client you will receive two identical events (e.g. leave) instead of two opposite event (leave and enter).

Actual Outcome

With the example above we received two identical event (e.g. leave).

Expected Outcome

We expect to receive two opposite events, leave and enter.

Failing Test Case / Pull Request

We are working on the PR! It will be created soon 🙂

• 🤩 I submitted a PR (Fix #7340 by correclty computing function name for push event #7341) with a fix and a test case.
• 🧐 I submitted a PR with a failing test case.

Environment

Server

• Parse Server version: 4.5.0
• Operating system: Node 12 on Heroku (Ubuntu)
• Local or remote host (AWS, Azure, Google Cloud, Heroku, Digital Ocean, etc): Heroku

Database

• System (MongoDB or Postgres): MongoDB
• Database version: 4.2.13
• Local or remote host (MongoDB Atlas, mLab, AWS, Azure, Google Cloud, etc): MongoDB Atlas

Client

• SDK (iOS, Android, JavaScript, PHP, Unity, etc): JavaScript
• SDK version: 2.10.0

Logs

Logging doesn't work well on our local or Heroku machines. We get %s instead of the actual value.
But we logged the event computed res.event and the message.event and seen the difference. You'll see the details of the bug with the coming PR.

Contributors

Discovered by @fbeiger and @percypyan from PINPODEV.

[mtrezza]

Thanks for reporting!

That's a great in-depth examination of the issue, we'll look forward to the PR.

To classify the bug severity, are you aware of any workaround to mitigate this issue?

[percypyan]

There is no workaround for all I know...

[fbeiger]

Well if all the subscriptions concerned are in the same app, you can create 1 subscription (with a bigger filter) and use the update event to interpolate logic. So for our precedent example, instead of having 2 subscriptions we can have:

const sub = await Parse.Query("MyCollection").subscribe()

sub.on("update", (object) => {
   if (object.get("myBoolean") === true) {
      // logic if true
   } else {
      // logic if false
   }
})

But this can lead to a lot of events being sent, and also you'll need to cache locally the previous value of myBoolean for each object (because now you can't have enter or leave events when myBoolean switches).

Now if the subscriptions are in different apps I think the only way to bypass this would be to add a "buffer" state for your object, i.e. instead of switching myBoolean from true => false (or vice versa), you'd need to do something like true => undefined => false. But now you have to ensure that your data will always go through this "buffer" state whenever you want to change myBoolean ...
We didn't think of this case because our subscriptions were all in the same app, but now I reckon it's a pretty big deal.

[percypyan]

Yes, that's true: I've answered too quickly. Those workarounds may work in some specific cases but aren't really sustainable, as explained by @fbeiger.

[mtrezza]

Thanks for providing more details.

I classify this issue as bug with severity S3 (normal - blocks non-critical functionality and a work around exists):

• Workaround for common use cases: Live Queries Server: wrong event returned when multiple subscription triggered #7340 (comment)

[parseplatformorg]

🎉 This change has been released in version 5.0.0-beta.1