disconnect runs the lifecycle callback only · explicit leave destroys the Actor at the Entry Spot
Guided views
Explore this system
Step through curated paths without changing the source diagram.
Beat
Next
ReadyChapter 01 / 01
Guided chapter
Diagram guideExplore this system
Inspecting compiled semantics
E ExportT ThemeS Style0 Reset+ Zoom in- Zoom outEsc Close
Find a node
⌕/
No matching nodes
Semantic passport
Verified source
Authored reach
Route probeChoose a start node
Pick two semantic nodes on the diagram
Choose the source, then the destination. Direction matters.
Semantic lensCompare system roles
Choose up to two semantic kinds. One reveals its real traffic; two compare only direct authored relationships.
Choose a kind to inspect its nodes and touching relationships.
Semantic radar
Building overview
Click nodeDrag to pan
Semantic radar needs more MAP space.
Interleaved self-steps (mermaid self-messages, in arrow order)
• After arrow 1 (STREAM ends): F fixes the current binding snapshot.
• After arrow 2 (notify callback): R runs the disconnected lifecycle callback; then F cleans up the binding after all notifications finish — both before the reconnect (arrow 3).
• Between arrows 4 and 5 (AuthenticateReq/Res): P resolves the existing Actor and binds its exact ActorRef.
• After arrow 11 (dispatch to Room handler): R marks the Actor and requests public leave.
• After arrow 12 (move to Entry Spot): E destroys the Actor — the terminal step.
Disconnect vs explicit leave
• Session Runtime = Framework Session Runtime. The first arrow is a physical STREAM termination (mermaid -x); it doesn't destroy the Actor or change Room membership.
• On reconnect, the Play Session finds the existing Actor and binds its exact ActorRef; because the Actor is already a member, JoinGameMsg returns the current GameState without new membership.
• LeaveGameMsg is one-way, so send completion doesn't prove destroy; the runner checks the Room leave callback and Entry Spot destruction per Actor. Host and guest each run this leave path.