Logging

The Rollerz SDK includes a built-in logging system that outputs structured messages to the browser console. Logging is disabled by default and must be explicitly enabled.

Enabling logs

Pass enableLogging: true in the init() options:

const sdk = window.RollerzSDK;

await sdk.init('my-game-id', {
  enableLogging: true,
});

When disabled (the default), all log methods are no-ops — zero runtime overhead.

How it works

The SDK creates an internal logger via createSDKLog(enabled). When enabled, it wraps the browser's console.debug, console.info, console.warn, and console.error methods, prefixing every message with [RollerzSDK]:

[RollerzSDK] init { gameId: 'my-game', bridgeUrl: 'http://...' }
[RollerzSDK] bridge ready
[RollerzSDK] sendAndWait { type: 'API_CALL', requestId: '...' }
[RollerzSDK] response { type: 'API_RESULT', requestId: '...' }
[RollerzSDK] openGame { provider: 'go3' }
[RollerzSDK] placeBet { provider: 'go3', betAmount: 100, betType: 'BASE' }

Each log call takes a message string and an optional metadata object:

log.debug('placeBet', { provider: 'go3', betAmount: 100, betType: 'BASE' });
//  console.debug('[RollerzSDK]', 'placeBet', { provider: 'go3', betAmount: 100, betType: 'BASE' })

Log levels

Level	Console method	What gets logged
debug	console.debug	Detailed flow: every bridge message sent/received, provider calls, dev-mode responses
info	console.info	Lifecycle events: SDK init, bridge ready
warn	console.warn	Potential issues: placeBet called without a session, invalid bet amounts
error	console.error	Failures: request timeouts, bridge errors

Filtering in DevTools

In Chrome/Edge DevTools, use the Console filter box and type [RollerzSDK] to show only SDK logs. You can also filter by log level (Verbose, Info, Warnings, Errors) to narrow the output further.

What gets logged

SDK lifecycle

Event	Level	When
init	info	sdk.init() is called — includes gameId and bridge URL
bridge ready	info	The hidden bridge iframe has loaded and is ready

Bridge communication

Event	Level	When
send	debug	A fire-and-forget message is sent to the bridge
sendAndWait	debug	A request is sent and the SDK is waiting for a response
incoming	debug	A message is received from the bridge
response	debug	A pending request received its response
response error	debug	The bridge returned an error for a request
request timeout	error	A request timed out (10s default)

Provider operations

Event	Level	When
openGame	debug	A game session is being opened
placeBet	debug	A bet is being placed — includes amount, boost, and provider name
placeBet [dev]	debug	A bet was handled locally by dev mode — includes the generated result
collect	debug	A round is being collected
collect [dev]	debug	A collect was handled locally by dev mode
placeBet without session	warn	placeBet was called before openGame
invalid bet amount	warn	Bet amount is not in the valid chip levels

SDKLog interface

The logger implements the SDKLog interface from @rollerz/types:

interface SDKLog {
  debug: (msg: string, meta?: Record<string, unknown>) => void;
  info:  (msg: string, meta?: Record<string, unknown>) => void;
  warn:  (msg: string, meta?: Record<string, unknown>) => void;
  error: (msg: string, meta?: Record<string, unknown>) => void;
}

Each method accepts a message string and an optional metadata object that gets passed to the console method as an additional argument.

Server-side logging

The SDK server (apps/sdk-server) has its own logging:

• Fastify logger: The server starts with { logger: true }, which outputs structured JSON logs for every HTTP request (method, URL, status code, response time).

Server logs appear in the terminal where the SDK server is running (or in Docker logs via docker compose logs).

Best practices

• Enable logging during development to trace SDK behavior and debug issues. The [RollerzSDK] prefix makes it easy to filter in DevTools.
• Disable logging in production by omitting enableLogging or setting it to false. This avoids console noise for end users and has zero runtime cost.
• Use the dev panel alongside logging — when dev mode is active, log messages show the locally generated bet results, making it easy to verify that your game handles each outcome correctly.
• Check the Network tab too — SDK logs show the logical flow (init, placeBet, collect), but the browser Network tab shows the actual HTTP requests the bridge makes to the server. Both are useful for debugging.