localMode regression in 5.5.0

[michaeltnguyen]

Calling statsig.initialize with localMode: true emits the following warning to the console:

StatsigLocalModeNetworkError: No network requests in localMode
    at new StatsigLocalModeNetworkError (/node_modules/statsig-node/dist/Errors.js:52:28)
    at StatsigFetcher.post (/node_modules/statsig-node/dist/utils/StatsigFetcher.js:29:35)
    at SpecStore.<anonymous> (/node_modules/statsig-node/dist/SpecStore.js:643:59)
    at step (/node_modules/statsig-node/dist/SpecStore.js:33:23)
    at Object.next (/node_modules/statsig-node/dist/SpecStore.js:14:53)
    at /node_modules/statsig-node/dist/SpecStore.js:8:71
    at new Promise (<anonymous>)
    at __awaiter (/node_modules/statsig-node/dist/SpecStore.js:4:12)
    at SpecStore.syncIdListsFromNetwork (/node_modules/statsig-node/dist/SpecStore.js:631:16)
    at SpecStore.<anonymous> (/node_modules/statsig-node/dist/SpecStore.js:217:55)

This can be reproduced with a one-liner:

statsig.initialize('secret-', { localMode: true });

The apis that statsig-node are trying to hit are:

• https://statsigapi.net/v1/download_config_specs
• https://statsigapi.net/v1/get_id_lists

This happens in 5.5.0 but not in 5.4.2 (the previous version).

[tore-statsig]

I think thats actually local mode working as intended, the only difference is now it prints to the console (this same error was thrown previously, just not printed)

cc @jacob-statsig

[michaeltnguyen]

Hi @tore-statsig , thanks for the response.

We are using localMode: true for unit tests, and that error is being printed for every single test. It's very noisy.

I think the intent of StatsigLocalModeNetworkError is to catch errors in my code. For example, if I'm attempting to make a checkGate call that hasn't been properly mocked / stubbed / overridden, it is a warning to fix my code.

I don't think this error should be thrown in the initialize call. Ideally, initialize would check the localMode flag and avoid calling download_config_specs and get_id_lists.

[jacob-statsig]

@michaeltnguyen Thanks for pointing this out. We will be replacing this error logging with a no-op on network requests when in localMode.