fix!: Do not add the targeting key as a custom attribute

[kinyoklion]

Stops targetingKey from being copied into the LaunchDarkly context as a custom attribute.

• A typo in the attribute loop compared the value of the key ($key === "targetingKey") instead of the attribute name ($k === "targetingKey"), so the attribute was never skipped.
• Every multi-context evaluation was therefore sending a redundant targetingKey attribute per sub-context, where it was visible to targeting rules and on the context in the LaunchDarkly UI.

Before, for {"kind": "multi", "organization": {"targetingKey": "org-key", "name": "the-org"}}:

{"kind":"multi","organization":{"key":"org-key","name":"the-org","targetingKey":"org-key"}}

Implementation details

Found during the weekly OpenFeature provider audit. OFP requirement 2.3 names targetingKey as the source of the context key, and 2.4 only requires attributes not named in that section to become custom attributes, so this was a spec violation as well as noise.

Only multi-contexts were affected in practice: for a single context the OpenFeature SDK keeps the targeting key outside the attributes, while a multi-context has to carry a targetingKey inside each per-kind attribute map. The fix is in the shared single-context builder, which handles both.

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

None.

Describe the solution you've provided

The attribute name is compared to "targetingKey", as was clearly intended by the surrounding code and its comment.

Describe alternatives you've considered

Filtering the attribute out in the multi-context builder only: that leaves the same latent bug in the single-context path if the SDK ever surfaces a targetingKey attribute there.

Additional context

Testing: make check (composer cs-check, composer phpstan, composer phpunit). The new test asserts both that the sub-context key is still taken from targetingKey and that no such custom attribute remains.

Link to Devin session: https://app.devin.ai/sessions/38a6eaf69fcf41109e136a1d0fe5e899
Open in Devin Desktop: https://app.devin.ai/desktop/session/38a6eaf69fcf41109e136a1d0fe5e899?variant=devin
Requested by: @kinyoklion

---

Note

Overview
Fixes a one-character logic bug in buildSingleContext where the skip check used $key === "targetingKey" (the resolved context key) instead of $k === "targetingKey" (the attribute name). key was already skipped correctly; targetingKey was not, so multi-context evaluations could emit a duplicate targetingKey custom attribute on each sub-context while still using it for the LD context key.

Adds testMultiContextTargetingKeyIsNotAddedAsAnAttribute to assert the sub-context key comes from targetingKey and that targetingKey does not appear in serialized context JSON.

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

[devin-ai-integration]

🤖 Devin AI Engineer

I'll be helping with this pull request! Here's what you should know:

✅ I will automatically:

• Address comments on this PR. Add '(aside)' to your comment to have me ignore it.
• Look at CI failures and help fix them

Note: I can only respond to comments from users who have write access to this repository.

⚙️ Control Options:

• Disable automatic comment, CI, and merge conflict monitoring

[devin-ai-integration]

@cursor review