Photon Realtime Custom Properties: Verifying State Consistency After External Backup Restoration

Confirmed facts for verification

To ensure that restored Custom Properties match the intended room state, use the following proven checks:

1. Canonical key set – Define a list of required property keys (e.g., player scores, turn index, map seed, version/timestamp). After restoration, confirm that every key exists and its value equals the snapshot taken before backup.
2. Deterministic hash – Serialize the full set of Custom Properties (sorted by key) and compute a SHA‑256 hash. Store this hash with the backup. After re‑applying the properties, recompute the hash locally and compare it to the stored value; a mismatch indicates missing, altered, or extra entries.
3. Readiness flag – Add a boolean Custom Property (e.g., "stateReady") that the host sets only after writing all expected properties. Clients wait for this flag to become true before executing any authoritative game logic.
4. Version or timestamp – Include a monotonically increasing version number or UTC timestamp in the properties. On join, reject the restoration if the incoming version is older than the last known version, preventing stale state from being used.

Likely explanation and practical steps

The hash and readiness flag together give both a completeness check and a synchronization point without adding noticeable latency. The version/timestamp guards against out‑of‑date backups, which is a common failure mode when a client re‑joins with an old snapshot. Keeping the total payload small (< 1 KB, roughly 10‑15 small key/value pairs) ensures that the property transfer during room creation stays well under typical network round‑trip times (< 100 ms) and avoids Photon’s server‑side limits.

Recommended workflow for developers

1. Before shutting down, serialize the room’s Custom Properties, compute the SHA‑256 hash, and persist both the property map and the hash (plus a version/timestamp) to your external storage.
2. When creating a new room for recovery, set the Custom Properties from the backup.
3. After setting the properties, compute the hash locally and compare it to the stored hash; if they differ, abort the recovery and log an inconsistency.
4. Set the "stateReady" flag to true only after all properties have been written.
5. Have each client, upon joining, wait for "stateReady" to become true and verify the version/timestamp is not stale before allowing gameplay to start.