Runtime Context #
All registered functions across all runtimes receive a
context as the first argument. This contains fields which depend on when and how the code is executed. You can extract information about the request or the user making it from the context:
The Go runtime context is a standard
context.Context type and its fields can be accessed as shown above.
If you are writing your runtime code in Lua, the
context will be a table from which you can access the fields directly.
|Go Context Key
|Lua Context Key
|A table of key/value pairs which are defined in the YAML configuration of the server. This is useful to store API keys and other secrets which may be different between servers run in production and in development.
|The mode associated with the execution context. It’s one of these values: “run_once”, “rpc”, “before”, “after”, “match”, “matchmaker”, “leaderboard_reset”, “tournament_reset”, “tournament_end”.
|The Nakama server version.
|Query params that was passed through from HTTP request.
|The user session associated with the execution context.
|The user ID associated with the execution context.
|The username associated with the execution context.
|The user session expiry in seconds associated with the execution context.
|The IP address of the client making the request.
|The port number of the client making the request.
|The match ID that is currently being executed. Only applicable to server authoritative multiplayer.
|The node ID that the match is being executed on. Only applicable to server authoritative multiplayer.
|Labels associated with the match. Only applicable to server authoritative multiplayer.
|Tick rate defined for this match. Only applicable to server authoritative multiplayer.
Go context #
The runtime context is distinct from the Go context. It is important that a
Context type be included in all server requests to avoid a potential overloading of the server with dead requests (i.e. requests from users who have since disconnected).
Inclusion of the
Context allows for the context cancellation - when a user’s HTTP connection to the server is closed - to be propagated across the entire chain of requests and avoid the processing and/or buildup of such dead requests.