A LiveOps configuration change is not small when it controls timed events, rewards, or player-visible state. The useful question is not “did the JSON validate?” but “what happens when this configuration arrives twice, late, missing a field, or races with an already-running server?”
Here is a compact failure-injection matrix I use before treating a configuration change as ready.
1. Apply the same version twice
Expected behaviour: the second apply is a no-op, or returns the stored result for that version. It should never duplicate a reward grant, event registration, or schedule entry.
Evidence to capture: configuration version, target scope, server receipt time, idempotency decision, and a redacted result code.
2. Deliver an older version after a newer one
Expected behaviour: the server rejects or safely ignores the stale version. A client timestamp alone is not enough; the server needs an ordering rule it owns.
Evidence to capture: current accepted version, incoming version, rejection reason, and whether a recovery path is needed.
3. Omit an optional field that becomes operationally important
Expected behaviour: a conservative server-side default is used, or the change is withheld. “Optional in the schema” should not silently mean “safe to guess”.
Evidence to capture: which default was applied and who can inspect that decision.
4. Target the wrong scope
Expected behaviour: a per-server change cannot become global because an identifier was blank, reused, or malformed. Scope validation should happen before mutation, not just in a dashboard preview.
Evidence to capture: resolved place/server scope and an authorization decision.
5. Restart between accepting and applying
Expected behaviour: recovery can distinguish pending, committed, rejected, and needs-review work. That prevents a restart from replaying a partially applied event as a new grant.
Evidence to capture: durable transition state and restart outcome.
The matrix is intentionally small. It gives a team something testable before a live event turns an ambiguous configuration into player-visible state.
For a Creator Store configuration workflow, see the exact LiveOps Goblin Config Builder. For the companion runtime boundary, see the LiveOps Goblin Runtime Kit. These are implementation tools, not a guarantee of reliability, uptime, or outcomes.
Top comments (0)