Investigate EndStream behavior in Block Stream publish service

[derektriley]

Currently when either a publisher or consumer is receiving an EndStream, there exists the chance that the message is not received and either side closes the connection immediately after sending the message. This has been observed in previewnet ({"from":"2026-05-13T19:19:06.933Z","to":"2026-05-13T19:24:46.783Z"}) where the BN tries to send a DUPLICATE_BLOCK message, immediately ends the stream, the CN side never receives the message but gets a socket closed exception and switches to another BN.

We may want to explore changing the protocol to have acknowledgments for these or on either side when sending an EndStream, expect the other side to close the connection, and if it's not closed within a timeout then close the connection.

[jsync-swirlds]

A question on this.
Assume the following scenario

• Publisher sends block header for block 5
• BN rejects with EndStream(DUPLICATE_BLOCK, 1004).
• Publisher has not received response yet, sends next batch for block 5.
  • Connection still open, but HTTP flow-control window is not being refreshed, so the send is paused.
• Publisher receives the end stream message

What does Publisher do in that case?

I would hope that the Publisher simply closes the connection and opens a new connection to send the correct next block (or similar action), but I am not sure if it would get stuck instead.

[timfn-hg]

If the consensus node tries to send a request to the block node, but that fails or times out before the EndStream is received, it is interpreted as a fatal event and the connection is closed, along with the block node being placed in a cool down period.

[jsync-swirlds]

My question is around receiving the EndStream message successfully while flow control is not allowing the CN to send more data. Does the CN get stuck (it cannot send, so it doesn't check responses), or does the CN handle the EndStream request even though it has a buffer of data waiting to send (in the Helidon client).

[timfn-hg]

Ah. If the CN receives an EndOfStream, we will terminate the connection immediately. Any in-progress requests will fail (socket closed or timeout) and if there are pending requests/items, they will not be sent either. The sending of requests and the receiving of responses are on separate threads so they don't block each other.

[jsync-swirlds]

Excellent, that works for what I have in mind.
Thanks.

FYI, I'm working on some flow-control improvements currently. Assuming that works (Helidon obeys the flow control directives), a fix for this issue should follow very shortly thereafter.

If this is causing major issues in testing we could implement a partial solution earlier, but that will be a little bit fragile, so we'd prefer to complete these in the above order if it's not overly burdensome.