Fork me on GitHub
#yada
<
2017-06-10
>
peterwestmacott13:06:40

I’m returning a core async channel to yada for SSE, does anyone know if I can register a callback for when the client closes the connection?

malcolmsparks13:06:16

Closing the connection will cause the channel to close. You can wait on that using alts. Presumably you're using a tap or sub?

peterwestmacott13:06:31

I’m not actually

peterwestmacott14:06:23

the events go to one client, as part of a WebRTC DataChannel handshake.

peterwestmacott14:06:52

“You can wait on that using alts.” - not sure I follow

malcolmsparks14:06:36

Take from the channel and if it closes you'll get a nil.

peterwestmacott16:06:06

hmm, I don’t want to remove data from the channel if it isn’t

peterwestmacott16:06:29

I’m trying with a manifold stream (which has a (closed? ...) function)

malcolmsparks16:06:34

Manifold is my preference too. Since this week's yada release manifold streams can be returned from response bodies. Try with periodically

peterwestmacott16:06:37

You’ve definitely lost me with periodically. I’ve got some state associated with an open SSE connection, and I want to know when I can discard it. I had hoped that I could perform this action manifold.stream/on-closed, but the stream never seems to be closed.

peterwestmacott16:06:55

Thanks for your help Malcolm, I think I can find a way around this.

peterwestmacott16:06:16

(and keep up the good work!)

malcolmsparks17:06:23

@peterwestmacott fwiw I've tested that on-closed works as a notification when the client closes the channel

malcolmsparks17:06:43

I'm using manifold here, and ms is an alias of manifold.stream

malcolmsparks17:06:30

The one thing I noticed is that ms/periodically can only be used as a manifold source so you cannot call on-closed on it.

malcolmsparks17:06:04

However, you can connect it with a normal buffered stream to achieve the requirement with the addition of a bit more code to create a new stream to connect to it.

malcolmsparks17:06:25

This is probably only an issue with periodically and most use-cases wouldn't need this extra step.

malcolmsparks17:06:31

But it does work as I understand manifold to work.

peterwestmacott18:06:26

Thanks for that. I wonder what I'm doing wrong... It looks like the problem is with my code.

malcolmsparks18:06:17

Yeah. A minimal working example helps. I've pushed to yada master. Generally I find bugs are in my code not in manifold or core.async ofc

peterwestmacott19:06:25

It appears that the on-close handler for the stream might not get called until I next try to use the stream.

malcolmsparks19:06:25

hmm. When I tested earlier I got the println as soon as the client disconnected - iirc

peterwestmacott19:06:05

it might depend if the client calls .close() on the event source, or the browser tab just gets closed?

malcolmsparks19:06:46

In my case I used curl and ctrl-c

peterwestmacott19:06:36

okay, when killing the webpage I have to wait for something to happen on the channel it seems

peterwestmacott19:06:59

I would imagine that in most circumstances this is fine, as the server generates the events

peterwestmacott19:06:51

In my case I’m bridging between two clients to establish WebRTC connections, so all the action is initiated on the clients - but I’m pinging the connection periodically now, so it will get cleaned up nicely if there is no longer anyone at the other end.

peterwestmacott19:06:05

thanks for your help!

peterwestmacott19:06:26

also - if your periodically was set to 400ms, the stream would be used almost immediately.