You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
feat(client): Abort resends when OrderMessages stops (#1571)
When `OrderMessages` stops, it aborts any ongoing resend HTTP `fetch` requests. Before this PR it stopped the iteration of resend streams but didn't stop the `fetch` requests.
## Changes
The `OrderMessages` now uses `AbortController` to store the `done` state. That signal is provided to the `fetchHttpStream` as an argument, and therefore the all `fetch` operations are stopped when `OrderMessages.stop()` is called.
Manual handling the list of ongoing resends is no longer needed in `OrderMessages`.
Added also `this.outBuffer.endWrite()` call to `OrderMessages.stop()` and `this.isDone()` check to `OrderMessages#addToOrderingUtil`. These are just optimizations and not strictly needed. In the current use case where `OrderMessages.stop()` is called only for stopped pipelines (see`messageStream.onBeforeFinally`) these optimizations don't have any effect.
### ComposedAbortSignal
Enhanced `composeAbortSignals` utility function so that the returned object contains a `destroy()` function. To avoid memory leaks it would be good to call the method when the composed signal is no longer used so that we can remove the listeners associated to the source signals. (If all source signals have short lifespan or there are just few listeners, the cleanup is not needed in practice.)
### Future improvements
- Is `stream.once('close', () => { abortController.abort() })` actually needed, or could we remove it?
0 commit comments