Photon Realtime rejoin during client rollout: actor slots not guaranteed across old and new builds

Actor Slot Behavior After TTL Expiry

When a rejoin attempt arrives after PlayerTTL has expired, the server no longer holds an inactive actor entry for that user. The client is therefore admitted as a new actor: it receives a new ActorNumber, and any state tied to the previous actor slot is lost. This is not an error or a room rejection — the join succeeds, just without slot continuity. Separately, if the room became empty and EmptyRoomTTL also expired, the room itself is destroyed, so the same UserID may end up creating or joining a different room instance entirely.

Exact TTL defaults and limits vary by Photon product, plan, and configuration, so do not design around an indefinite rejoin window. Verify your actual values in the Photon dashboard for your App ID.

Mixed Builds Sharing One Room

Photon Realtime is a transport layer: it delivers an event code plus payload to every subscribed client and does not enforce a shared schema between builds. Practical behavior with old and new builds in one room:

• Unknown event codes: the old client still receives the event; if its code has no handler for that code, the event is typically ignored by application logic.
• Changed payloads on known codes: behavior depends on your deserialization. A removed field or changed type can produce silent bad data, a null-reference, or a hard exception on the old client.
• Room stability: these failures are client-side. A bad payload will not crash the room or disconnect others, but a crashing or desynchronized client still corrupts gameplay consistency.

For a zero-downtime rollout, keep wire compatibility: reserve new event codes for new features, add fields instead of renaming or retyping them, and gate new events behind a room property or version check.

Cloud vs. Self-Hosted Criteria

Stay on Cloud if managed operations matter more than custom logic. Move to self-hosted only if you need authoritative plugins, custom admission rules, or controlled draining — and accept the upgrade burden.

Verification Before Migrating

1. Create a test room with a short PlayerTTL, disconnect, wait past expiry, and rejoin with the same UserID; log whether the ActorNumber is restored or reassigned.
2. Run old and new builds in one room, send a new-only event code and an extended payload, and record old-client behavior and exceptions.

One diagnostic detail that changes the recommendation: are you serializing with Photon's native types or a custom library (Protobuf, MessagePack)? That determines whether payload mismatches fail silently or throw, and therefore how strict your version gating must be.