[kinyoklion]

Requirements

• I have added test coverage for new or changed functionality
• I have followed the repository's pull request submission guidelines
• I have validated my changes against all supported platform versions

Related issues

OpenFeature provider spec (OFP) Requirements 2.2.1 and 2.3.x in launchdarkly/sdk-specs.

Describe the solution you've provided

In a multi-context, if an individual context had a targetingKey that was not a string, the converter silently dropped that whole kind with no log. For example, {'kind': 'multi', 'user': {'targetingKey': False, 'key': 'user-key'}, 'org': {...}} produced only the org context.

OFP 2.2.1 requires each top-level attribute to become a single context. Section 2.3 applies the key rules within each individual context, using its targetingKey in place of the OpenFeature targeting key. Under those rules, a non-string targetingKey is not usable, so the provider falls back to a string key. If there is no key, the provider produces an invalid context and logs an error (2.3.5), rather than dropping the kind.

The converter now treats a non-string nested targetingKey as absent and logs a warning, matching how a non-string key is handled (2.3.4.1), then applies the normal key rules. test_create_multi_context_with_invalid_targeting_key asserted the old dropping behavior, so it is updated. A new test covers the case with no fallback key.

Describe alternatives you've considered

Keeping the drop and only adding a log. That would still lose targeting for a kind that has a valid key, which the spec does not allow.

Additional context

This changes behavior only for the malformed input above. Found during the weekly OpenFeature provider audit.

Link to Devin session: https://app.devin.ai/sessions/f7bc946afe8c41a28cf7f3f497fc8b9d
Open in Devin Desktop: https://app.devin.ai/desktop/session/f7bc946afe8c41a28cf7f3f497fc8b9d?variant=devin

SDK-3496

---

Note

Overview
Fixes multi-context conversion when an individual kind has a non-string targetingKey. Previously that kind was silently omitted from the built context; it now logs a warning, treats targetingKey as unset (same pattern as a bad key), and continues with normal key resolution via the string key when present.

Tests now expect a full multi-context (e.g. user kept with key 'user-key') plus the warning, and add coverage where invalid targetingKey and no string key make the overall context invalid instead of dropping only that kind.

^{Reviewed by Cursor Bugbot for commit 4be37ad. Bugbot is set up for automated code reviews on this repo. Configure here.}

[devin-ai-integration]

I'll fix CI failures and address comments from users with write access. I'll skip comments containing "(aside)".

• Disable automatic comment, CI, and merge conflict monitoring