PlayerFaultCode

What a player-facing surface may be told about a failure that came from code the platform did not write. Deliberately coarser than the internal fault taxonomy: it says what a player can act on and never names an engine, a module, a function or a limit. The full detail is in the developer surfaces (gameModelEvents, computeModuleRuns, userCodeFaults).

enum PlayerFaultCode {
  USER_CODE_ERROR
  USER_CODE_TOO_SLOW
  USER_CODE_LIMIT_EXCEEDED
  PLATFORM_BUSY
  PLATFORM_ERROR
  BUDGET_EXCEEDED
  RATE_LIMITED
  QUOTA_EXHAUSTED
  WALLET_EMPTY
  SPEND_CAP_REACHED
  TEMPORARILY_DISABLED
  INVALID_REQUEST
  NOT_ALLOWED
  NOT_FOUND
  UNAUTHENTICATED
  WRONG_DATACENTER
  APP_UNAVAILABLE
}

Values

`PlayerFaultCode.USER_CODE_ERROR`

The app's own code failed while running.

`PlayerFaultCode.USER_CODE_TOO_SLOW`

The app's own code ran past the time it is allowed.

`PlayerFaultCode.USER_CODE_LIMIT_EXCEEDED`

The app's own code exceeded a per-call resource ceiling (gas, fuel, memory, depth, database operations, response size).

`PlayerFaultCode.PLATFORM_BUSY`

The platform could not start the work in time. The app's code never ran. Retrying is correct.

`PlayerFaultCode.PLATFORM_ERROR`

A platform failure. Retrying is reasonable.

`PlayerFaultCode.BUDGET_EXCEEDED`

A per-minute allowance for this app is spent; it returns on the next window.

`PlayerFaultCode.RATE_LIMITED`

This caller is asking too often. It arrives ONLY as a thrown error, never in band on a result, and extensions.retryAfterMs carries the wait. That number is the milliseconds REMAINING in the current fixed window at the moment the refusal was built, not a fixed backoff, so a second refusal inside the same window carries a smaller number: treat it as a deadline from receipt and do not reuse a cached one.