Hello! We started to use GrowthBook relatively rec...
# give-feedback
n
Hello! We started to use GrowthBook relatively recently & we believe we found a bug that blocks us from using experimentation feature. Context In SDK configuration -> attributes we have keys following JS object access notation e.g.
user.targetingKey
,
user.email
, etc. Using dev tools we figured out that if we pass an object like
{ user: { targetingKey: "1234", email: "<mailto:joe@example.com|joe@example.com>"  } }
, our experiments are always skipped for all users with message "Skip because missing hashAttribute" (hashAttribute being set as
user.targetingKey
) even though
user.targetingKey
is (sort of?) specified. Problem In order to fix this, we tried to pass literal keys with dots e.g.
{ "user.targetingKey": "1234", "user.email": "<mailto:joe@example.com|joe@example.com>" }
& it fixed experimentation but broke feature flag conditions (e.g.
IF user.targetingKey = "3456"
lines in GB settings) which worked correctly with nested objects. This seem to work as described in any SDK, but, as a matter of fact, we use SDKs for React & .NET. Extra Additionally to the bug itself, dev tools make it feel like nested objects aren't supported at all which doesn't quite correlate with SDK setup instructions shown in GB itself (see screenshots attached)
f
Thanks for finding this. Looks like a bug where only targeting conditions support nested keys, but not the experiment hash attribute. I'll make a GitHub issue to track this. As a workaround, you can specify attributes in a flat structure without nesting or dots in the keys. This will work in all SDKs for both targeting and hashing.
Copy code
{
  "userTargetingKey": "1234",
  "userEmail": "..."
}
🙌 1
n
Thanks! Sounds good 👍
f
For reference - https://github.com/growthbook/growthbook/issues/4432 I think this will require updating all of our SDKs, which may take a bit of time, so using a flat attribute structure is definitely best for now.