feat: Verify per-context private attributes are not applied to other contexts

[kinyoklion]

Adds events/context properties coverage for private attributes declared in a context's _meta.privateAttributes leaking onto other contexts — the Ruby SDK bug fixed in launchdarkly/ruby-server-sdk#416, which the existing suite could not detect.

• New subtest: two identify events on one client, the first context declaring selfPrivate private, the second not — the second must not have it redacted.
• New subtests (both kind orderings): one multi-kind context where only one kind declares selfPrivate private — the other kind must not have it redacted.
• A globally configured private attribute is expected redacted in every assertion, so an SDK cannot pass by dropping its configured private attributes along with the per-context ones.
• No new capability gate: this is required behavior for every SDK, so all SDKs run it.

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

Implementation details

Why existing tests miss it

makeEventContextTestParams builds one client per test param, and every context that param then generates comes from a single data.ContextFactory with identical _meta.privateAttributes. An SDK that merges per-context private attributes into its long-lived configured list (rather than a per-context copy) therefore leaks only attributes that are already expected to be redacted. The multi-kind factories are also blind to it: they either declare no per-context privates, or declare them only on the kind filtered last (data.NewContextFactoriesForExercisingAllAttributes gives org just name while other carries Private("a","c")), and the leaked names do not exist on the other kind.

What the new tests do

CommonEventTests.eventContextPrivateAttributeScoping is called at the end of EventContexts, so it runs for server-side, client-side, and PHP SDKs. Each context carries selfPrivate, globallyPrivate, and visible; globalPrivateAttributes is configured as ["globallyPrivate"].

• Sequential case: identify selfPrivate-declaring context (expect selfPrivate + globallyPrivate redacted), then identify a context that declares nothing private (expect only globallyPrivate redacted). Pre-fix: Authenticate release asset downloads with GITHUB_TOKEN #416 Ruby redacts selfPrivate from the second context too.
• Multi-kind case: org + user in one context, only one kind declaring selfPrivate private; run once per kind so the leak is caught regardless of the order an SDK filters individual contexts in.

Both cases still assert globallyPrivate is redacted, which is what distinguishes a correct fix (copy the list) from a wrong one (stop applying configured privates).

Testing

make build, make lint (0 issues), and make test pass. SDK-level validation is in progress: the new subtests are being run against SDK contract test services, including the Ruby SDK before and after #416.

Alternatives considered

Adding more eventContextTestParams entries — rejected, the leak is only observable across two contexts with different private attributes within one client, which that table cannot express.

Link to Devin session: https://app.devin.ai/sessions/6e3076285f2849919b966a4f801075ca
Requested by: @kinyoklion

---

Note

Overview
Adds eventContextPrivateAttributeScoping at the end of EventContexts, so server-side, client-side, and PHP SDKs all run it.

The new coverage catches SDKs that merge _meta.privateAttributes into a long-lived global list instead of a per-context copy (e.g. Ruby server SDK before #416). A sequential identify case sends one context that marks selfPrivate private, then another that does not—only globallyPrivate (from globalPrivateAttributes) must be redacted on the second event. Multi-kind subtests run for both org and user as the kind that declares selfPrivate, so redaction cannot leak across kinds when filtering one kind at a time.

Every assertion still expects globallyPrivate redacted, so passing by dropping all configured private attributes along with per-context ones fails the suite.

^{Reviewed by Cursor Bugbot for commit 62615b4. 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]

Validated against 4 real SDK contract-test services

Ran the locally built harness (this branch) against contract-test services built from source. Full events/context properties path each time.

Results — the 3 new subtests pass everywhere the SDK has the fix

SDK	3 new subtests	full events/context properties
Go server 7.15.6	✅ pass	✅ 110 ran / 0 failed
Node server (js-core server-node)	✅ pass	✅ 182 ran / 0 failed
Python server	✅ pass	110 ran / 4 failed — all pre-existing¹
Ruby server main (has ruby-server-sdk#416)	✅ pass	110 ran / 4 failed — all pre-existing¹

¹ single-kind, allAttributesPrivate, slash-prefixed attribute name/* fails identically with a baseline harness built from origin/v3, so it is unrelated to this PR.

Negative control: the test really does catch the bug it was written for

Reverting the ruby-server-sdk fix locally (@private_attributes + context.private_attributes → .concat(...)) and restarting the service:

• ❌ private attributes of one context are not applied to later contexts — FAILS. The second identify event, whose context declared nothing private, wrongly redacts selfPrivate:

  item[0] JSON property "context" JSON property "selfPrivate" not found,
  JSON property "_meta" JSON property "redactedAttributes" got more items than expected: [0]: "selfPrivate"
  full value was: [{"context":{"_meta":{"redactedAttributes":["selfPrivate","globallyPrivate"]},
    "key":"EventContextPrivateScopingNone...","kind":"user","visible":"3"},"kind":"identify"}]
  

• ❌ ...other kinds of the same context (declared by org) — FAILS (user kind also loses selfPrivate).
• ✅ ...(declared by user) — still passes, because Ruby filters org first. Good argument for keeping both orderings in the test; a single-ordering version would only catch this 50% of the time.

Ruby file was restored afterwards; nothing committed in that repo.

Regression: whole events section, new harness vs origin/v3 baseline

SDK	this branch	baseline origin/v3
Go	436 ran / 0 failed	433 ran / 0 failed
Ruby	320 ran / 6 failed	317 ran / 6 failed

Exactly +3 tests, and the Ruby failure lists are byte-identical (diff → no output). No existing tests broken and no event-sink state leaking between tests.

No changes suggested to the test expectations. Written by Devin

[devin-ai-integration]

SDK validation

Ran the 3 new subtests (events/context properties/private attributes of one ...) 3x against each SDK's own contract test service, plus the full events/context properties group with both the PR binary and a baseline binary built from the base branch, to separate new failures from pre-existing ones. Every SDK was run on the harness line(s) its CI actually pulls.

No SDK fails the new tests, and no SDK gains a new failure. 18 services PASS, 2 N/A (no/incapable test service), 2 BLOCKED (need a macOS runner / a physical Roku), 1 pending.

Negative control: reverting launchdarkly/ruby-server-sdk#416 (+ back to .concat) makes the sequential subtest and the multi-kind "declared by org" subtest fail, while "declared by user" still passes — which is why both kind orderings are included.

Per-SDK results

SDK	Verdict	Line(s) run	Version	Commit	Exit codes	Notes
go-server-sdk	PASS	v2 + v3	7.15.6	88bd0dc	0,0,0 / 0,0,0
python-server-sdk	PASS	v2 + v3	9.16.1	5da1515	0,0,0 / 0,0,0	v3-only /~1ssn failures pre-existing, and absent from the v3.0.0-alpha.6 tag CI pins
ruby-server-sdk	PASS	v2	8.14.0	2fd26ea	0,0,0	includes #416
php-server-sdk	PASS	v2	6.8.2	80f0d88	0,0,0
erlang-server-sdk	PASS	v2	3.11.2	4bb97ec	0,0,0	OTP 24 only
rust-server-sdk	PASS	v2	3.2.0	e26d224	0,0,0
haskell-server-sdk	PASS	v2	4.6.0	aab4645	0,0,0	built with system GHC 8.8.4
java-server-sdk	PASS	v2 + v3	7.15.0	2a98583	0,0,0 / 0,0,0
dotnet-server-sdk	PASS	v2 + v3	8.16.0	7a9529c	0,0,0 / 0,0,0
dotnet-client-sdk	PASS	v2	5.9.5	7a9529c	0,0,0	run as net8.0 on Linux, not CI's macOS target
node-server-sdk (js-core)	PASS	v2 + v3	9.13.0	965008f	0,0,0 / 0,0,0
shopify-oxygen (js-core)	N/A	v2 + v3	0.1.19	965008f	1,1,1	HTTP 400 on client creation for the whole events group, identical on baseline; its CI skips event.*
cpp-server-sdk	PASS	v2 + v3	3.13.1	120b79a	0,0,0 / 0,0,0	Beast backend only, not the -curl jobs
cpp-client-sdk	PASS	v2	3.11.4	120b79a	0,0,0
node-client-sdk	PASS	v2	3.4.3	91b619c	0,0,0
electron-client-sdk	N/A	—	—	5ed0bb6	—	no contract test service in the repo
flutter-client-sdk	PASS	v2 + v3	4.20.2	a11df74	0,0,0 / 0,0,0	Dart implementation via flutter test, headless Linux
android-client-sdk	PASS	v2 + v3	5.15.0	347ca2c	0,0,0 / 0,0,0	emulator API 25; v3-head-only /~1ssn failures are newer than its v3.1.0-alpha.6 pin
ios-client-sdk	BLOCKED	—	—	5bfd8f8	—	ContractTests is Apple-platform only; needs a macOS + Xcode runner
roku-client-sdk	BLOCKED	—	—	fb5c24b	—	needs sideloading to a physical Roku; its CI runs lint + package only
js-core browser/react/react-native/vue	pending	v3	—	965008f	—	still running

Each PASS row was checked to have actually executed the new subtests (Test Summary: ... 5 ran, subtests listed as executed rather than SKIPPED) and to be unaffected by that repo's suppressions file / TEST_HARNESS_PARAMS. Full logs (3 runs + PR/baseline group runs per SDK) were kept per session.

Rollout note: several repos pin a released harness rather than a branch tip (dotnet downloads the latest v2 release; python/go/java/dotnet pin v3.0.0-alpha.6; android pins v3.1.0-alpha.6), so these subtests only reach those CI jobs once a new v2 release / v3 alpha is cut.

[devin-ai-integration]

Addendum — the js-core client-side workspaces finished, all PASS with no new failures (js-core 965008f):

Workspace	Verdict	Line(s) run	Version	Exit codes
node-client	PASS	v2 + v3	4.0.2	0,0,0 / 0,0,0
browser	PASS	v2 + v3	4.9.4	0,0,0 / 0,0,0
vue	PASS	v2 + v3	0.2.0	0,0,0 / 0,0,0
react-native	PASS	v2 + v3	10.19.4	0,0,0 / 0,0,0
react	PASS	v2	4.1.12	0,0,0
electron	PASS	v2	0.0.1	0,0,0

Test Summary: 65 total, 60 skipped, 5 ran on v2 and 66 total, 61 skipped, 5 ran on v3 for each; browser/vue/react ran under Playwright chromium on Xvfb, react-native on a headless API-31 emulator. The group run against the baseline binary is failure-free for every workspace, so no suppression entries are needed.

That closes out the run: 24 services PASS, 2 N/A (standalone electron-client-sdk repo has no contract test service; js-core shopify-oxygen's service 400s on the whole events group, pre-existing and skipped in its CI), 2 BLOCKED (ios needs a macOS + Xcode runner, roku a physical device).