Open emilm opened 1 month ago
Just curious: what's the use case for setting your own id?
Either way: I'm not against exposing that functionality if we can find a nice way to integrate it into the API.
Thanks!
The idea is to have an unique identifier per subscription client so you can distinguish them on the server when tracking / holding a list of active connections, so you can add / remove them based on that ID in the dictionary. Some graphql clients just send 0 others send a GUID.
Otherwise you need to assign them on the server which seems difficult with the current server side APIs.
The idea is to have an unique identifier per subscription client so you can distinguish them on the server when tracking / holding a list of active connections, so you can add / remove them based on that ID in the dictionary.
Do you want a unique identifier per subscription or per client? Guessing per subscription, but if it was per client then setting the connection payload with this function might be a better fit.
Thank you!
#[derive(Serialize, Deserialize)]
#[serde(rename_all = "camelCase")]
struct CustomPayload {
id: String
}
Then
let (client, actor) = Client::build(con).payload(
CustomPayload { id: "123".to_string() }).unwrap()
.await.unwrap();
Still shows up as session id "0" on the server.
Maybe I am doing this wrong. Forgive me. My rust knowledge isn't that good yet.
I guess the subscription level code doesn't get my id. I would assume it's per subscription this id comes into play. So I am not sure if this is carried on from the client to the sub. It needs to be the standard id property that is sent like in the first post.
I am not sure if this should be valid but to keep track of the graphql subscriptions on the server one expects a unique ID. This code to send your own string is out of reach:
Should it be made possible to provide your own or should the server not rely on it?