Race condition sending subscription while socket is connected, but before op=connected

[jhansche]

1. Subscribe to queryA
   • it is not connected yet, so it will trigger reconnect.
2. Socket opens, thus state=CONNECTED
   • Sends op=connect
3. Subscribe to queryB
   • SOCKET is connected (state=CONNECTED), but we haven't received op=connected yet.
   • BUG: it will call sendSubscription now, because it only checks current state
4. Server responds to (2) with op=connected
5. On op=connected, we replay pending subscriptions, including the one that was already sent in (3)

That results in sending JSON over the socket in this order:

1. socket CONNECT
2. send op=connect
3. send op=subscribe (query A)
4. receive op=connected
5. send op=subscribe (query A)
6. send op=subscribe (query B)

That results in having 2 subscriptions for query A, and one for query B, when we should only have one of each.

I have a unit test that proves this, and a fix will be forthcoming.

[jhansche]

It seems that there might still be a race condition here, but much harder to write a test for it.

If we try to subscribe to query B at exactly the same time (separate threads) as we receive the op=connected response (so between executing lines 231..234), it's possible that the call to subscribe() will see that isConnected()==true, because the flag has already been set at line 231, and so it sends the subscription while also adding it into the subscriptions map. Then line 234 re-sends all pending subscriptions, including the query B subscription that was already sent, resulting in query B being subscribed twice.

Any thoughts how we might be able to write a test for that?