Why aren't you testing the following scenario?

1. Receive message
2. Send confirmation
3. Restart connection
4. Don't receive a message

I guess its due to pt 4 - we cannot check if websocket is empty without hacky ways like timeouts

One more test worth considering is to send confirmation twice.

1. Receive a message
2. Send confirmation
   • Message should be deleted from DDB
3. Send confirmation again
   • Deleting a non-existent DDB message should not cause an error
4. Connection should still be active (not dropped by tunnelbroker)

In D9578#281084, @bartek wrote:

Why aren't you testing the following scenario?

1. Receive message
2. Send confirmation
3. Restart connection
4. Don't receive a message

I guess its due to pt 4 - we cannot check if websocket is empty without hacky ways like timeouts

yes, that's the case

In D9578#283026, @michal wrote:

[...] I guess its due to pt 4 - we cannot check if websocket is empty without hacky ways like timeouts

Could we do something like this:

1. Send message
2. Receive message
3. Send confirmation
4. Restart connection for receiver
5. Send another message
6. Receive only the second message

makes sense, added