Nethereum: Websocket subscription for new block headers stuck at block numbers of multiples of 200

This issue has me quite puzzled. The following simple piece of code gets stuck exactly at block numbers multiple of 200 when running against BSC nodes:

using Nethereum.JsonRpc.WebSocketStreamingClient;
using Nethereum.RPC.Reactive.Eth.Subscriptions;
using System.Reactive.Linq;

public class Program
{
    public static async Task Main(string[] args)
    {
        using (var client = new StreamingWebSocketClient("wss://bsc-ws-node.nariox.org:443"))
        {
            var subscription = new EthNewBlockHeadersObservableSubscription(client);
            subscription.GetSubscriptionDataResponsesAsObservable().Subscribe(block => { Console.WriteLine($"{DateTime.Now} > {block.Number.Value} "); });
            await client.StartAsync();
            await subscription.SubscribeAsync();
            Console.ReadKey();
        }
    }
}

15/05/2022 12:02:55 > 17821798 
15/05/2022 12:02:57 > 17821799 
15/05/2022 12:03:00 > 17821800 

and it stays there. I don’t get any timeouts or any kind of errors.

The similar Javascript web3 code doesn’t show this problem:

let Web3 = require('web3')

const web3 = new Web3(new Web3.providers.WebsocketProvider('wss://bsc-ws-node.nariox.org:443'))

web3.eth.subscribe('newBlockHeaders', function (error, result) {    
    if (!error) {
        console.log(new Date().toLocaleString() + " > " + result.number);
    }
});

15/05/2022, 12:02:55 > 17821798
15/05/2022, 12:02:58 > 17821799
15/05/2022, 12:03:01 > 17821800
15/05/2022, 12:03:04 > 17821801
15/05/2022, 12:03:06 > 17821802
15/05/2022, 12:03:10 > 17821803

With nariox and my own local BSC node it happens always. Not every 10 minutes (time for the BSC to mine 200 blocks) since starting the client, but exactly at every block multiple of 200.

Funnily, with moralis’ node it only gets stuck sometimes. And one time I received a duplicated notification, which was simultaneously received by the Javascript client:

15/05/2022 11:42:57 > 17821399
15/05/2022 11:43:01 > 17821400
15/05/2022 11:43:01 > 17821400
15/05/2022 11:43:04 > 17821401

not sure if that it also happened at a 200 boundary was a coincidence or not.

The only thing I’ve found where number 200 has any relevance is that the BSC re-elects validators every 200 blocks, but I can’t see how this could have anything to do with streaming connections.

My local node shows this when it happens:

lvl=dbug msg="RPC connection read error"              err="websocket: close 1000 (normal)"

so from the node’s side it looks like just a normal client disconnection.