[BUG] Memory leak when migrating from v5 to v6

[andresz1]

Is there an existing issue for this?

• I have searched the existing issues

SDK Version

6.3.1

Current Behavior

Memory increases over time and is not garbage collected

Expected Behavior

Memory is like it was before

Steps To Reproduce

We rewrote the optimizely instance creation from:

const DEFAULT_DATAFILE_OPTIONS = {
  autoUpdate: true,
  updateInterval: 5 * 60 * 1000 // 5 minutes
}

const DEFAULT_EVENTS_OPTIONS = {
  batchSize: 10,
  flushInterval: 1000
}

const DEFAULT_TIMEOUT = 500

const LOGGER_LEVEL = process.env.NODE_ENV === 'production' ? ERROR : INFO

export default class OptimizelyAdapter {
  static createOptimizelyInstance({
    options: optionParameter,
    sdkKey,
    datafile,
    optimizely = optimizelySDK,
    eventDispatcher = optimizelySDK.eventDispatcher
  }) {
    const options = {...DEFAULT_DATAFILE_OPTIONS, ...optionParameter}
    optimizely.setLogLevel(LOGGER_LEVEL)
    optimizely.setLogger(optimizely.logging.createLogger())
    if (!datafile && typeof window !== 'undefined' && window.__INITIAL_CONTEXT_VALUE__?.pde) {
      datafile = window.__INITIAL_CONTEXT_VALUE__.pde
      sdkKey = undefined
    }

    const isServer = typeof window === 'undefined'
    const optimizelyInstance = optimizely.createInstance({
      sdkKey,
      datafileOptions: options,
      datafile,
      eventDispatcher,
      ...DEFAULT_EVENTS_OPTIONS,
      defaultDecideOptions: isServer ? [optimizely.OptimizelyDecideOption.DISABLE_DECISION_EVENT] : []
    })

    return optimizelyInstance
  }
}

To:

const DEFAULT_DATAFILE_OPTIONS = {
  autoUpdate: true,
  updateInterval: 5 * 60 * 1000 // 5 minutes
}

const DEFAULT_EVENTS_OPTIONS = {
  batchSize: 10,
  flushInterval: 1000
}

const DEFAULT_TIMEOUT = 500

const LOGGER_LEVEL = process.env.NODE_ENV === 'production' ? ERROR : INFO

export default class OptimizelyAdapter {
  static createOptimizelyInstance({options: optionParameter, sdkKey, datafile}) {
    if (!datafile && typeof window !== 'undefined' && window.__INITIAL_CONTEXT_VALUE__?.pde) {
      datafile = window.__INITIAL_CONTEXT_VALUE__.pde
      sdkKey = undefined
    }

    const isServer = typeof window === 'undefined'

    const projectConfigManager = sdkKey
      ? createPollingProjectConfigManager({sdkKey, datafile, ...DEFAULT_DATAFILE_OPTIONS, ...optionParameter})
      : createStaticProjectConfigManager({datafile})

    const eventProcessor = createBatchEventProcessor({
      ...DEFAULT_EVENTS_OPTIONS,
      ...optionParameter
    })

    const odpManager = createOdpManager()

    const logger = createLogger({
      level: LOGGER_LEVEL
    })

    return createInstance({
      projectConfigManager,
      eventProcessor,
      odpManager,
      logger,
      defaultDecideOptions: isServer ? [OptimizelyDecideOption.DISABLE_DECISION_EVENT] : []
    })
  }
}

The instance is created in the server during bootstrap and we just create one. We would like to keep the current behaviour as it is (not using the disposable flag). I will try to do some memory snapshots but I was wondering is something is wrong since we only changed this part following your migration from v5 to v6 guide

SDK Type

Browser

Node Version

JS SDK

Browsers impacted

No response

Link

No response

Logs

No response

Severity

No response

Workaround/Solution

No response

Recent Change

No response

Conflicts

No response

[junaed-optimizely]

@andresz1, Thanks for reporting this. Your instance creation code looks correct based on the migration guide. To help us investigate, could you provide a few more details?

• Node version and runtime environment (e.g., Express, Next.js, NestJS, etc.)
• How are you using the instance and more importantly, how are you calling the decision APIs? It would be nice to have more implementation details.
• Memory snapshots (If possible)

The v6 architecture creates separate service objects (event processor, config manager, ODP manager) each with their own internal queues, timers, and event emitters. If the instance is created once and reused, these should remain stable - but knowing the call patterns above will help us pinpoint where the growth is happening.