server push silently fails for reconnected clients

[yatesco]

Hi, this is almost certainly something I am doing/not understanding, so assume the bug is in my head. However, I can't see where it is, hence this ;).

I don't need to 'preserve' user state across disconnects or sessions etc., so I have a new UUID created for each 'client':

(sente/make-channel-socket!
taoensso.sente.server-adapters.http-kit/http-kit-adapter
{:user-id-fn :client-id})

However, each 'client' does register a bunch of server side state (which materialised views it wants for example), but for simplicity I want to treat disconnects/reconnects as a new connection:

• client resubmits the 'I'm interested in XYZ'
• server no longer pushes to disconnected clients

However, I am noticing the following behaviour:

• start the system
• add a client
• everything is lovely
• turn off the server (or stop the component system)
• client immediately starts logging the warnings
• start the system
• client notices, reconnects and resubmits the 'I'm interested in XYZ' data
• client now receives no new data from the server
• server tries to push to two clients, the old disconnected one and the new one

To be clear, the server periodically pushes data to the client when it notices one of the views that the client is interested in has changed. Imagine the server time is such a view. Also, I am not explicitly removing disconnected clients so I will be calling closed over send-fn's for clients that are no longer connected.

I see neither an error when sente tries to push to the old disconnected client or any warnings when it tries to push to the new client.

As I say, I am sure it is my misunderstanding but I don't understand:

• why sente isn't complaining when pushing to a disconnected client
• why a reconnect causes the server to no longer push to that data

Any hints?

Thanks!

[ptaoussanis]

Hi Colin,

A little busy atm so can't look into this in detail right now, but didn't want to leave you hanging - so some quick thoughts:

why sente isn't complaining when pushing to a disconnected client

This is expected. Sente's API defines async push to an invalid or disconnected client uid as a noop. Uids are expected to come and go (sometimes temporarily while they experience connection difficulties, etc.).

why a reconnect causes the server to no longer push to that data

This could be caused by your user-id somehow being inconsistent pre/post reconnect...

{:user-id-fn :client-id}

I'd start by looking here. Are you specifying a persistent :client-id? If not, the default behaviour is for a client-id to be randomly generated on connection. That'll mean that the client-id changes every time a client connects. Is your server expecting that?

See here for a detailed explanation of how the client+user ids work. They're inherently a little tricky due to the way browsers work, but not too bad once you understand what's actually going on.

It sounds to me like you might want {:user-id <client-id>} with a <client-id> that persists between re/connections? That might be a little tricky since you'll need some persistent + secure data source for calculating each client's id.

So, literally, can you think of any data available to a client that:

1. Uniquely identifies itself
2. Persists for however long you need it to (e.g. the life of a particular tab)
3. Isn't easily guessed or forged by other clients

If you can, then that might make a good client-id. If not, then you may need a different strategy.

To be clear: these requirements aren't requirements of Sente, they're intrinsic requirements of identity.

Does any of that help?

[ptaoussanis]

I should have added that something like

(defonce random-client-uuid (encore/uuid-str)) ; Define on first js load
{:user-id random-client-uuid} ; Plug into chsk constructor

May do the trick for the specific case of persistence that needs to only live as long as a particular page refresh.

[ptaoussanis]

Closing this for now, please feel free to re-open if you're still having any issues.

[yatesco]

No problem - I meant to respond earlier but got side tracked elsewhere. Thanks for your suggestions!