Open Jasper-M opened 1 year ago
What happens if you provide a dispatcher that waits for the completion of active fibers?
Same result. The error seems to happen when submitting a new task to the dispatcher. So the dispatcher is already closed even before the task is started.
I wonder how we best avoid that error. Gate submission through something?
Perhaps ideally the cancellation triggered by interruptAfter
should backpressure until onClose
has been called? Assuming onClose
will always be called at least once.
I guess the most sensible thing might be to make clients themselves "closable" resources and reject all events after the client has been closed. But then all methods that don't return a Resource
yet (def client
, def mkClient
, def stub
) would have to change incompatibly just for this.
@Jasper-M You are welcome to give it a go, I do not have the bandwidth atm. I suppose it is time to spring clean that client interface in a major bump that allows breaking changes.
To be more precise,
onClose
can be called on the underlyingFs2StreamClientCallListener
while the client (and its dispatcher) are already closed. I don't have a full end-to-end example, but it comes down to this:Output:
So
interruptAfter
preemptively stops the stream after which the surrounding resource is immediately closed. ButonClose
still gets called afterwards and invokes the already closed dispatcher.