Session persistence data is lost on (probably?) photon instance crash/netsplit
tracked
TapGhoul
This is part bug report, part feature request.
- Play any world that has persistence data
- Have vrchat disconnect with the error "Your connection to VRChat timed out. Verify connection and try again." - preferably where the entire instance times out, not just you. (maybe photon crash?)
- Rejoin the world
All persistence data for that session will have been lost.
Ideally, VRC would either periodically permanently flush that data even without disconnect, or have some backup method to save persistence data in the case of a photon crash, so games where multiple hour long sessions occur don't result in total data loss.
Alternatively, some way for the client to recover state upon reconnect in the case of a server crash (some kind of server-provided short-lived signed copy of the data that can be sent and reverified on reconnection, if it has a timestamp older than the server's copy) would be a nice to have, as it can prevent VRC-side infra netsplits resulting in total data loss in many cases.
This was seen on US-east servers today, multiple times. Entire instance disconnects and total data loss for all users in the instance. The state gets reset back to how it was prior to loading into that instance initially - it is all rolled back/forgotten.
Log In
StormRel
tracked
TapGhoul
Possible implementation idea for user-side backup copy submission - KDF(user id || server-private session id || windowed timestamp)
Ideally, embed some kind of either incremental counter or timestamp directly within the signed data (not part of the keying material) to understand if the server's copy is newer (i.e. there was no crash)
Server-private session ID being a session ID generated and reported back as the user joins (I assume this is something you guys already have internally) to verify the session ID. Really though, any kind of secret data - but a secret session ID like this is a nice pseudo-random(ish) bit of keying material that doesn't need to be rotated separately.
+ with a little allowance for clock drift/delays (similar to a TOTP) - you only really want this for a user reconnecting after losing connection to vrc in the case the server was unable to submit new session info as a backup plan, and ideally the photon server's state should be authoritative over the client's signed backup copy.