SDKsWASM

Logging

Configure WASM SDK log levels and use operationID to correlate client and OpenIMServer call logs.

WASM SDK logs are primarily used to diagnose browser login and business API calls. Development and staging environments can emit detailed SDK logs. Production should retain only necessary errors and tracing fields and must avoid logging tokens, message bodies, file URLs, or other sensitive data.

A logging flow generally combines the SDK login configuration, the operationID for one call, diagnostic fields in the SDK response, and your application's own structured logs.

Log levels

Pass browser SDK logging options through InitAndLoginConfig when calling login(). logLevel uses the LogLevel enum. From most to least verbose, the values are Verbose (6), Debug (5), Info (4), Warn (3), Error (2), Fatal (1), and Panic (0). Use LogLevel.Debug for development diagnostics. In production, warnings or errors are usually sufficient.

The current browser SDK login wrapper writes the configuration using params.logLevel || 5. Because LogLevel.Panic has the numeric value 0, it is treated as falsy and falls back to Debug. To reduce log output, use LogLevel.Fatal or LogLevel.Error instead of relying on Panic.

Avoid leaving the most verbose logging enabled in production. Increase the level temporarily based on the environment, a staged feature flag, or an explicit user-initiated diagnostic flow.

Recommended log levels

Scenario	Recommended configuration	Description
Local development	`LogLevel.Debug`, `isLogStandardOutput: true`	Inspect SDK call details in the browser console.
Integration or staging	Temporarily use a more detailed level when needed	Correlate user IDs, conversation IDs, error codes, and OpenIMServer logs.
Production default	Use `Warn` or `Error` and disable unnecessary console output	Reduce noise and sensitive-data exposure while retaining structured application errors.
User diagnostic mode	Temporarily enable more detailed logs and explain the collection scope	State which fields are collected and follow privacy and compliance requirements.

Configure the log level

After creating the SDK instance, set the logging options in the login() parameters. Browser login still requires userID, token, Platform.Web, apiAddr, and wsAddr.

import { getSDK, LogLevel, Platform } from '@openim/wasm-client-sdk';

const openimsdk = getSDK({
  coreWasmPath: '/openIM.wasm',
  sqlWasmPath: '/sql-wasm.wasm',
});

await openimsdk.login({
  userID,
  token,
  platformID: Platform.Web,
  apiAddr,
  wsAddr,
  logLevel: LogLevel.Debug,
  isLogStandardOutput: true,
});

Parameters

Parameter	Type	Required	Description
`logLevel`	`LogLevel`	No	Controls the verbosity of SDK runtime logs.
`isLogStandardOutput`	`boolean`	No	Whether to write SDK logs to the browser console. Use it during development and temporary diagnostics.

errCode and errMsg are diagnostic fields in a response, not logging configuration parameters for login().

Trace one call with operationID

operationID identifies the call chain for one SDK operation. Most WASM SDK methods accept it as the final optional parameter. When omitted, the JavaScript wrapper generates a UUID for the call and passes the same value to the SDK core. Use the response's operationID to correlate client logs with OpenIMServer logs and determine which processing stages handled a request.

const operationID = crypto.randomUUID();

try {
  const response = await openimsdk.getConversationListSplit(
    { offset: 0, count: 50 },
    operationID,
  );

  appLogger.info('openim_api_success', {
    operationID: response.operationID,
    action: 'get_conversation_page',
  });
} catch (error) {
  appLogger.error('openim_api_failed', {
    operationID,
    action: 'get_conversation_page',
    error,
  });
  throw error;
}

For ordinary calls, omit operationID and let the SDK generate it. Generate and pass one explicitly only when the application needs to correlate a specific call precisely with OpenIMServer logs. Use a new value for every call; do not share one operationID across unrelated requests.

operationID is not a user identity, permission credential, conversation ID, or business idempotency key. It cannot replace a token, conversationID, clientMsgID, or another business identifier. If a business flow contains multiple SDK calls, generate a separate operationID for each call and use an application trace ID to correlate the complete flow.

Record business context

Include the current route, business action, operationID, errCode, errMsg, and necessary target identifiers in structured logs. Do not write tokens, complete message bodies, raw file URLs, or private user fields to frontend logs.

Was this page helpful?