Subscription stream doesn't close when connection closes about fuels-ts

[nedsalk]

Well, it seems a good night's sleep was needed for this one. This issue is solved in #1615 (comment).

[arboleya]

This issue description looks contradictory to me, so much so that I can't reconcile that you are filing a bug and simultaneously saying it's not a pressing issue for the same PR that is still open. If there is an issue with that PR, that should be fixed over there before that gets merged, and this issue is unnecessary.

[nedsalk]

I already spent quite some time trying to get this to work, fix it in that PR and not file this issue. Unfortunately, I couldn't get to the root of the problem. With filing this issue I wanted to unblock #1615 because this bug is not tied to introducing submitAndAwait per se, but to the underlying infrastructure and how we're using the streams API. Any SSE connection that's read via the streams API and that gets closed by the server isn't registered as closed by that same streams API.

[arboleya]

Are you saying this issue was introduced after #1374 instead of #1615?

[nedsalk]

Correct. I'll try resolving this specific issue but we can also specify a timeout for subscriptions as is suggested by the vm client team, in which case an infinite loop would never be possible because we'd be closing the stream ourselves after that timeout. It wouldn't directly solve this issue, but this issue then should never happen because we'd close the stream ourselves at one point which'd end the stream correctly with a {value: undefined, done: true}.

[arboleya]

Then, I'd say we should pause #1615 and address this matter first. There's no harm in delaying the submitAndAwait, especially considering it'd also make the use of subscriptions more prevalent.