Logging

WASM SDK logs help diagnose browser sign-in and business API calls. Use the log level and standard-output options to control the amount of SDK output.

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 LoginParams 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.

Recommended log levels

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

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 application ID used to prevent duplicate processing. 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.

Related pages

• User authentication
• Send your first message
• Send a message