test(realtime): Testing echoMessages=true and echoMessages=false

[alex-georgiou]

At first I was hoping that something could be done so I could somehow query the server and have it tell me that all pending messages up to now have been sent. I scanned the code and docs for the SYNC message and for the ping/HEARTBEAT mechanism.

I thought I could send a message followed by a ping and then if I got the ping back but not the message, I could assume that the message was not echoed. Then I wouldn't have to stall the tests for an arbitrary amount of seconds.

When the above didn't work, I had a look at the implementations in other languages.

1. In .NET, there is a timer waiting for 10 seconds before asserting that the message was not returned.
2. In GO, there is a similar timer for 15 seconds.
3. In IOS, the wait is for 60 seconds, which sounds more correct given that other connection timeouts are also set to 60s, but slows down the tests.

I set my timeout to 15 seconds.

[alex-georgiou]

I just thought of another solution that would avoid waiting for an arbitrary duration:

1. Realtime1 connects with echoMessages = false
2. Realtime2 connects
3. Realtime1 sends message1 to a channel
4. Immediately after, Realtime2 sends message2 to that same channel
5. Realtime1 waits to see if message2 arrives but not message1.

I'm not sure if this will work because I don't know if message ordering is guaranteed. Let me know if you'd like me to attempt this, but it would diverge from the tests I saw in the other languages.

[mattheworiordan]

I'm not sure if this will work because I don't know if message ordering is guaranteed

Yes it is for a channel in the same region, so that will work, that is definitely a better way of approaching it

[alex-georgiou]

@mattheworiordan I have combined both tests into one so that there is no wait for an arbitrary amount of time.

I have removed some unnecessary tests as you suggested.

[mattheworiordan]

BTW. I think the monitorConnection method supports monitorConnection(test, rt1, rt2);

[alex-georgiou]

@mattheworiordan I have uploaded improved code.

I think this version is better because it also checks for messages arriving in the expected order.

There is a longer list of callbacks but hopefully with the comments I added it should be readable. Let me know.

[mattheworiordan]

What is this second function? The signature for subscribe is subscribe(name, callback(msg)), there is no third aargument?

[alex-georgiou]

Actually there is an optional third argument which is a callback:

  RealtimeChannel.prototype.subscribe = function(/* [event], listener, [callback] */) {

It allows me to do exactly what I wanted, i.e. to do stuff after the listener is subscribed to the channel.

[mattheworiordan]

Ok, that's an undocumented API and I expect may change in the future, not sure why that's even in there as it's rather unrelated to the subscribe method itself. For clarity however, given the third callback is undocumented, I would prefer to simply use channel.attach(function(err) { ... do somethign .. }) over the subscribe as it's a lot clearer what is happening. Sorry once again, no idea why that argument exists.

[SimonWoolf]

no idea why that argument exists.

FWIW you and Paddy have discussed this before -- see 1b151df. Paddy argued strongly in favour of having a callback parameter (as opposed to throwing an exception) to notify a channel attach fail or a channel in a failed state, for a call which triggers an implicit attach.

[mattheworiordan]

But that is a different point entirely @SimonWoolf. This is a second callback on a subscribe method which has in implicit attach, whereas that discussion was in relation to whether we throw an exception immediately or pass the exception to the callback. This callback is unrelated to that discussion as far as I can tell?

[SimonWoolf]

It's not the same issue as the discussion on whether to throw or call the callback in the already-failed case.

Apologies if I'm not being clear. Matt's comment was that he wasn't sure "why that argument exists". Since the outcome of the earlier discussion was that we should call the callback (rather than throw), that relies on that argument existing, hence why I linked to it.

[alex-georgiou]

@mattheworiordan OK I am trying to follow the discussion. I think I now understand the semantics of attach and subscribe after reading the docs and code more carefully. If I understand correctly attach is an event that fires once a connection has been established, and subscribing to a channel's event can cause an implicit attach if the channel is not already attached.

I think I got it now, will attempt again and let you know.

[mattheworiordan]

Since the outcome of the earlier discussion was that we should call the callback (rather than throw), that relies on that argument existing, hence why I linked to it.

How does attach rely on subscribe's 2nd callback argument?

[SimonWoolf]

How does attach rely on subscribe's 2nd callback argument?

The discussion linked was on a change in RealtimeChannel.prototype.subscribe...?

[mattheworiordan]

My bad, I am stupid, those pesky little plus signs are there to confuse people like me :) I do think we should still avoid using the undocumented callback API though as it's likely to change and testing it simply obfuscates the code and is likely to break in future. Sorry for the confusion.

[alex-georgiou]

@mattheworiordan OK I believe I now call attach explicitly before subscribing. This should ensure correct execution order while avoiding the undocumented callback.