fix: empty stream state on broadcast

[EnriqueL8]

When a broadcast is attempted and the steam state hasn't been initialise it caused a nil pointer.

Two ways to solve this:

• If the stream state is nil, set an empty one as part of broadcast but that means no connections will receive those messages until that map updates
• Wait for a least one connection on this stream to start and then start broadcasting. At least one connection will receive the messages for the stream whilst it's connected

I've gone for the latter one. We perform best-effort delivery for broadcast, so it could be argued to do the former, any thoughts appreciated!

[codecov-commenter]

Codecov Report

All modified and coverable lines are covered by tests ✅

Comparison is base (ea9c63d) 100.00% compared to head (5a8e0ab) 100.00%.

❗ Current head 5a8e0ab differs from pull request most recent head 891eea2. Consider uploading reports for the commit 891eea2 to get more accurate results

Additional details and impacted files

@@            Coverage Diff            @@
##              main      #129   +/-   ##
=========================================
  Coverage   100.00%   100.00%           
=========================================
  Files           79        79           
  Lines         6473      6476    +3     
=========================================
+ Hits          6473      6476    +3     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[nguyer]

I'm not sure that this solution is consistent with the way we have viewed these types of connections throughout our architecture. The "Broadcast" function is expected to be non-blocking and any code should be able to call it regardless of whether any clients are current connected. The Broadcast function specifically is also not intended to be a durable message queue (as opposed to the RoundTrip function), which I think these changes have begun to alter. It is expected that if something is broadcasted (a TX receipt for example) while my client is not connected, if I am interested in that receipt, when I need to query for it when my client connects. I expect to be caught up on batches that I have missed (the durable part of the stream), but broadcasts are a different thing altogether.

[nguyer]

Does waitStreamConnections block here if nobody is connected?

[EnriqueL8]

Yes it does block

[EnriqueL8]

Exactly what I thought that is why I left it for the reviewer to decide on which option is best - just ignore that message if no connection are available or wait until a connection is available. You are leaning towards the former but does that mean that "starting" a stream means start listening from now , not from the beginning of the events this stream cares about. If we are fine with that, I am happy to make my original change of just setting the state of stream without any connections on the first broadcast for the stream

This will not be true I expect to be caught up on batches that I have missed and continue to be true if you are late joiner to a broadcast stream. Only will occur if you reset the stream.

[nguyer]

Broadcasts are not durable, so if I (as a websocket client) start listening, I only expect to get broadcasts that happen while I'm connected

[nguyer]

This will not be true I expect to be caught up on batches that I have missed and continue to be true if you are late joiner to a broadcast stream

That's fine. Broadcasts and batches that go through the RoundTrip are different in this regard.

[EnriqueL8]

Just to clarify we are broadcasting batches as well so batching and delivery methods are completely different and configured independently.

Have pushed the simpler change to just populate the stream state