RTN15a

[ricardopereira]

No description provided.

[ricardopereira]

Well, I realised right now that what I did here is more about RTN15d.

[tcard]

listener1 should still work, shouldn't it? Maybe you can instead of failing inside unconditionally, add a condition that it has reached the reconnection. That way we test that previous subscriptions still work.

[ricardopereira]

Done 551d534.

[ricardopereira]

Connection state is only maintained for a brief period, up to a minute, so if a client is disconnected for a longer period connection state cannot be resumed

@tcard What do you think, should I test this? I think it's a server behaviour.

[tcard]

@ricardopereira I don't see how we could test that meaningfully. Maybe @mattheworiordan does.

[ricardopereira]

I think this should be rebased with #228 fixes.

[mattheworiordan]

Why are you resubscribing, you have a listener already defined above on line 1322. Also, subscribing after you're connected is not going to work because it's quite possible the message has already been received at this point.

[mattheworiordan]

Connection state is only maintained for a brief period, up to a minute, so if a client is disconnected for a longer period connection state cannot be resumed

@tcard What do you think, should I test this? I think it's a server behaviour.

You're right, you can't test that behaviour. We can however test that a connection resume fails i.e. this would happen after connection state is lost. We can test this by changing the connection key explicitly so that a connection cannot be resumed

[ricardopereira]

Rebased with master with changes: b274f12.

[mattheworiordan]

If this test is testing the failure condition, this description should reflect that.

[ricardopereira]

Done 6c55525.

[mattheworiordan]

LGTM

[ricardopereira]

@tcard PTAL

[tcard]

LGTM