Whenever I update my nakama server, for example with new RPC functions etc. I get invalid auth token errors as my client is still using the stored token instead.
I’d like to make the server a bit more resilient to this problem, but for that i’d need to know where/how the session gets stored.
As i’m running the server in a Kubernetes cluster with a separate Couchdb instance I would’ve expected this to work, but the fact it doesn’t makes me think sessions get stored on disk instead so i’d need to add some persistence for a specific path to get it working the way I want.
- Versions: Nakama 3.9.0, Docker, Nakama-Unity 3.2.0
- Server Framework Runtime language Go
The session tokens are stored in memory and aren’t persisted to database (by design) to ensure performance is kept high.
What you are seeing is done by design to force developers to actively think about session expiration, session refresh, and re-auth flow. From experience, this has been a major pain in live games and we’ve had to make sure this becomes a development pain first 
Hope this helps.
1 Like
That I can understand, however what would be an advised solution / best practice in this case?
currently upon startup i have the client connect using the device id, and upon getting a “401 Unauthorized” i unset the current auth token and try to connect again, however this sometimes results in still not being able to connect.
however what would be an advised solution / best practice in this case?
Have an error handler where if the error is 401, then you try to refresh the token, if that comes back with a 401, then you re-authenticate and the cache token + refresh token.
however this sometimes results in still not being able to connect.
This is odd - what is the error you get when it fails to connect?
I think that’s mostly on my code, but i’ll have to go through the code 
I noticed i haven’t implemented some parts there, as i used the FishGame example to start off of, but that didn’t implement the usage of the refreshtoken 
Thanks for the help, and i’ll give an update later once that part of the code has solidified a bit more or I encounter a different issue.
1 Like
What happens to a socket if the session is expired mid-game? I tested this in my dev-env with session lifetime set to a really low amount of 5 seconds, but I didn’t experience any socket disconnection on session expiration. Is my observation correct?
Yes that’s the correct observation. A live, established, authenticated socket will never be kicked from the server (by default - it can be enforced via server runtime).
1 Like