Store hash value not updated by ldClient.identify()

[danielfinke]

Describe the bug
Potentially an extension of #13. The Store instance is created with an initial hash argument but does not update the hash when ldClient.identify() is called. When launchdarkly-electron-client-sdk is being used, the electron-json-storage library frequently cannot handle the length of the hash generated from the LDUser provided by ident.getUser().

To reproduce

1. Initialize launchdarkly-electron-client-sdk in the Electron main process, e.g. with user { key: '123', name: 'user', email: '[email protected]' }.
2. Initialize the client in a renderer process.
3. Update the identity of the user using identify(). Use an LDUser with a lot of custom props.
4. When the client clears flags, an ENAMETOOLONG exception will be thrown if getFlagsKey creates a key that is too long from the JSON stringification of the user.

Expected behavior

1. It is possible to supply a hash in the options provided to LDElectron.initializeInMain (this would be in https://github.com/launchdarkly/electron-client-sdk).
2. When identify() is called, the hash argument provided updates the hash in the Store closure in case it wasn't provided when the Store was created (to avoid the ENAMETOOLONG error on subsequent calls to identify()).

Logs
Log from our app in which abTestingService acts as logger for the SDK and adds some extra logs.
log.log

SDK version
launchdarkly-electron-client-sdk 1.6.1
launchdarkly-eventsource 1.4.0
launchdarkly-js-client-sdk 2.19.1
launchdarkly-js-sdk-common 3.3.1

Language version, developer tools
Node.js v12.18.3
NPM 7.6.0
TypeScript 3.9.9
Webpack 4.46.0

OS/platform
macOS Big Sur 11.3.1
Electron 11.4.4

Additional context
Let me know if I can provide any more context!

[eli-darkly]

This sounds like a very Electron-specific issue— is there a reason you filed it in js-sdk-common?

[danielfinke]

I submitted it here because the root issue is that the Store instance (in this repo) has a stale hash, though as far as I can tell it's unlikely to manifest as much unless you're using the Electron SDK or some other home-grown solution that is subject to filename length in the Store backend. Technically the hash will still be stale no matter which client lib you're using though

[eli-darkly]

Well, I may just not be reading your description correctly, but I'm having trouble understanding which of these two statements (if any) correctly characterizes what you're seeing:

1. The user hash never gets updated when identify is called. In the case of Electron, this leads to a later error related to filename length. In other SDKs, the consequence is something else.
2. The user hash normally does get updated when identify is called, except in the case of Electron, where an error related to filename length can sometimes stop it from being updated.

[danielfinke]

Hey Eli, sorry for the confusion. It’s the former. I’ve observed the file name length error using the Electron SDK, but the hash is not updated regardless of which SDK is being used.

…

On Tue, May 25, 2021 at 5:28 PM Eli Bishop ***@***.***> wrote: Well, I may just not be reading your description correctly, but I'm having trouble understanding which of these two statements (if any) correctly characterizes what you're seeing: 1. The user hash never gets updated when identify is called. In the case of Electron, this leads to a later error related to filename length. In other SDKs, the consequence is something else. 2. The user hash normally does get updated when identify is called, except in the case of Electron, where an error related to filename length can sometimes stop it from being updated. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#42 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAT42CY6FYCZ7B5F3O6DQCTTPQ6BXANCNFSM45QNYDEQ> .