nakama.tournamentsGetId and nakama.sqlQuery returns different data

Runtime Framework
1

I’m trying to update tournament metadata state with nakama.sqlQuery(“UPDATE leaderboard …”) but the changes is not reflected when I tried to get the new state from nakama.tournamentsGetId(), but I see my changes if I query from nakama.sqlQuery(“SELECT metadata FROM leaderboard …”)

Consider this sample code:

const updateQuery = `UPDATE leaderboard
      SET metadata = jsonb_set(
          metadata,
          '{cycle}',
          to_jsonb($1::int),
          true
      )
      WHERE id=$2`

nakama.sqlQuery(updateQuery, [1, tournamentId])
const tournamentStateAfter = nakama.tournamentsGetId([tournamentId]).at(0)
const dbStateAfter = nakama
        .sqlQuery(
          `SELECT id, metadata::text as metadata
           FROM leaderboard
           WHERE id = $1`,
          [tournamentId]
        )
        .at(0)
      Helper.log(logger, "debug_test_cycle_after", {
        id: tournamentId,
        runtimeMetadata: tournamentStateAfter?.metadata,
        dbState: dbStateAfter
      })

the runtimeMetadata would still contains cycle: 0, but the dbState already incremented to 1 cycle: 1

why is that? Is it because the `nakama.tournamentsGetId used cached version and updating from nakama.sqlQuery didn’t bust this cache? if so, what’s the recommended way to update tournament metadata?

PS: above fn called when tournament is reset, e.g. through initializer.registerTournamentReset

  1. Versions: Nakama 3.26, Linux binary
  2. Server Framework Runtime language (If relevant) : TS/JS

Media:

2

@doaortu Tournament and Leaderboard creation in Nakama is considered immutable. This is done so its possible to aggressively cache the information across the mesh network of nodes for the game which overall reduces the overhead with score updates to a single query for high performance.

When you drop to SQL to update the Tournament’s metadata it will not be reflected into the cached state of the Nakama server(s). I think we cover in our documentation that when Leaderboards/Tournaments are created its immutable.

Let’s take a step back. Would you be able to share more on why you want to update the Tournament metadata after its been created?

3

Hi, thanks for replying.

I think we cover in our documentation that when Leaderboards/Tournaments are created its immutable.

Ah so that’s why, sorry I’m too focused looking how to update the tournament state in the docs, so I don’t really see this section.

Let’s take a step back. Would you be able to share more on why you want to update the Tournament metadata after its been created?

Ok so we have this cycle functionality that will cycle the config (the reward, etc) everytime the tournament reset (from the resetSchedule). and currently we rely on tournament metadata to decide and calculate which cycle willl be picked.

so if the tournament state is immutable, how can we update the state related to the tournament itself? something like score, metadata, etc? or should we persist these state somewhere else (storage, maybe?) ?

Thank you in advance

4

Ok so we have this cycle functionality that will cycle the config (the reward, etc) everytime the tournament reset (from the resetSchedule). and currently we rely on tournament metadata to decide and calculate which cycle willl be picked.

@doaortu I’m a bit confused; we have done reward distribution for players with regular Leaderboards and Tournaments and it has never required the use of an update into Tournament metadata.

Within the game framework we created (Hiro) for example we use a JSON definition to describe the rewards for players and in Event Leaderboards we have structured it so the claim happens on demand by the active playerbase (even on an expired phase) while in regular Leaderboards and Tournaments it can be done with the initializer.RegisterLeaderboardReset function.

5

cycle the config (the reward, etc) everytime the tournament reset

Ah I missed this part. I think that the way to solve this is to use the start time of the current active phase as a seed for the selected reward distribution settings you want to use for that active phase.