Concurrent sub requests lead to success(200OK) and not 304/503(Locked)

[dilshansdoq]

Subject of the issue

Hi,
So the scenario is if user send multiple subscription requests to same topic from same ws session in very small amount of time (miliseconds), there is a probability of user getting all sub ctrl responses as 200 OK.

Scenario: 10 concurrent sub requests

Success case:

• one 200OK
• 9 304 or 503

Failure case:

• more than one, 200OK
• less than 9, 304 or 503

Your environment

Server-side

• web.tinode.co, api.tinode.co
• Your own setup:
  • platform - Linux
  • version of Tinode server - v21.0
  • database backend - MongoDB
  • standalone

Client-side

• Your own client. Describe it:
  • Transport : websocket
  • Testing tool : nodejs with ws library
• Tindroid: Android app
  • Android API level - 31,32,33
  • Hardware - Midrange, Flagship device (Pixel 7 Pro, Samsung S23Ultra)
  • Client was slightly modified such that, whenever a pres:what:msg is received on me topic, (it will try to get latest data by sub:topic:get:data -> note:recv -> leave:topic). Push notification is also enabled.
• Version of the client, e.g. 0.21.0

Steps to reproduce

The idea is to make concurrent subscription requests to single topic from single session, and you will get more than one 200OK. This is not 100% reproducible, as you will have to do multiple iterations of same test. Most of the times, i would say 6 out of 10 times, user will receive only one 200OK and all other either 304(already subscribed) or 503(Locked). But this is reproducible for sure. I have attached a nodejs script that i used to get failed case.
multi-sub-issue.zip

Expected behaviour

Server should only send one 200 OK response, no matter the number of subscription requests server got for the same topic from same session.

Actual behaviour

Server sent more than one 200 OK response, in response to n number of concurrent requests of sub:topic(unique topic) from same session.

Server-side log and Client-side log

logs.zip

[or-else]

Thanks for the report. The following changes should fix it:

dd1af03
f9de546

Please verify.

[dilshansdoq]

Yes, seems like this particular issue has been fixed.
Thanks