Photon Server Room Persistence and Client Rejoin Interoperability After Version Upgrade

Answer

The server clears cached events (the lastN history) only when the persisted room state cannot be read or when persistence is disabled. This happens in two scenarios:

1. Persistence disabled – RoomOptions.Persistence flag is false, so room state lives only in memory; any server restart or upgrade wipes the cached events.
2. Persistence enabled but schema mismatch – A major version upgrade changes the persistence serialization format. Without running the official migration tool, the server fails to deserialize the stored room data, treats the room as absent, and therefore discards the cached events.

Interaction with RoomOptions.CleanupToRoom

When CleanupToRoom is true (the default), the server removes a room’s persisted state as soon as the last player leaves. If persistence is disabled or the persisted data is unreadable, the cleanup simply removes the in‑memory room object, which also drops the cached events. If CleanupToRoom is false, the room remains in the persistence store after it empties, preserving the cached events until the next server start or a successful migration.

Reliability of RejoinAndReconnect()

RejoinAndReconnect() will restore the room’s properties and player list only if the server successfully loads the persisted room state. When cached events are lost because of the scenarios above, the client receives a successful rejoin event but the lastN buffer is empty or contains only events that occurred after the rejoin. Gameplay logic that depends on recent history must therefore resynchronize (e.g., by requesting a full state snapshot) after rejoining.

Steps to Verify and Mitigate

1. Confirm that RoomOptions.Persistence is true and note the provider (SQLite, MySQL, custom).
2. Check the release notes of the source and target Photon Server versions for any persistence‑schema changes.
3. If a schema change is indicated, back up the current persistence database and run the Photon Server SDK Migration Tool to convert it to the target version’s schema.
4. Start the upgraded server with the migrated database and have a client call RejoinAndReconnect() on a known room ID; verify that the client receives a OnRejoinedRoom callback and that room properties match the pre‑upgrade values.
5. If the rejoin fails, inspect the server logs for persistence deserialization exceptions and ensure the client SDK version matches the server’s expected protocol version.

Missing Diagnostic Detail

To give a definitive recommendation, we need to know: Is persistence enabled, and which persistence provider are you using? If persistence is disabled, the only solution is to enable it or accept that cached events will not survive upgrades; if persistence is enabled, the migration procedure above applies.