Variation methods do not validate `key` presence

[baweaver]

Describe the bug

Variation methods do not validate that the key attribute is present in the provided user Hash:

ld_client.variation('flag_name', {}, 'default value')

...but this attribute is necessary to retrieve a live value, calling this with variation_detail will reveal that calls lacking the key attribute will not hit LaunchDarkly, and will instead provide the default value.

I believe this is a bug as it can cause subtle issues in users codebases without warning.

To reproduce

Call variation or variation_detail without a key attribute provided to the User hash.

Expected behavior

Warnings or errors on absence of key.

[eli-darkly]

Well, the behavior of returning the default value if the user has no key is not a bug— it's expected behavior, given that the key is a required property of all valid users and you can't evaluate flags without a valid user.

I agree that it'd be desirable to log a warning, just as it currently does if you pass a nil user. The other server-side SDKs, to my knowledge, do log a warning in that case and we should add similar behavior.

[baweaver]

That would be great, mostly saw a few users footgunning on it earlier and was about to add a warning to our wrapper to make sure they knew that was the case.

[eli-darkly]

Thanks for bringing it to our attention. We do try to keep the behavior for things like this consistent across all of the SDKs, and we clearly missed a point there. I've filed it as a bug, although I'm not sure what our time frame is for the next Ruby SDK release— it'll just depend on what else is going on.

[eli-darkly]

We've released version 6.2.1 which adds this log warning.