Skip to content

fix: Update java-sdk-internal to 1.12.2 to report all-private attribute names as references - #415

Open
abelonogov-ld wants to merge 1 commit into
andrey/event-durability-tier1-bufferfrom
andrey/escape-all-private-redacted-names
Open

abelonogov-ld wants to merge 1 commit into
andrey/event-durability-tier1-bufferfrom
andrey/escape-all-private-redacted-names

Conversation

@abelonogov-ld

@abelonogov-ld abelonogov-ld commented Oct 23, 2026 •

Copy link
Copy Markdown
Contributor

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

Stacked on andrey/event-durability-tier1-buffer, which moved java-sdk-internal to 1.12.1.

Picks up java-core#228, released in java-sdk-internal 1.12.2. The iOS counterpart is ios-client-sdk#544.

Describe the solution you've provided

_meta.redactedAttributes is a list of attribute references. When every attribute is private (allAttributesPrivate, or an anonymous context in a feature event), java-sdk-internal 1.12.1 listed each attribute's raw name. A name that starts with a slash, such as /ssn, reads back as the path to an attribute named ssn, so the list named an attribute other than the one that was removed. 1.12.2 lists AttributeRef.fromLiteral(name).toString() instead: /~1ssn for that name, and the name itself for any name without a leading slash. The Go and JavaScript SDKs write the same form.

1.12.2 contains only that fix. Both launchdarkly-android-client-sdk and shared-test-code move to it.

EventProcessorPrivacyTest.allAttributesPrivateReportsEachNameAsTheReferenceThatNamesIt checks the posted payload for attributes named /ssn, /a~b and c/d. It expects /~1ssn, /~1a~0b and c/d, and fails on 1.12.1 with [/a~b, /ssn, c/d].

Describe alternatives you've considered

None. The redaction is java-sdk-internal's, which the event processor reuses through OutboundEventBuffer.

Additional context

Event output only, and only for attribute names that start with a slash.


Note

Overview
Bumps launchdarkly-java-sdk-internal from 1.12.1 to 1.12.2 in launchdarkly-android-client-sdk and shared-test-code, picking up the fix where _meta.redactedAttributes uses proper attribute references when every attribute is private (allAttributesPrivate).

With 1.12.1, literal names starting with / (e.g. /ssn) were listed as raw strings, which could be misread as paths to different attributes; 1.12.2 reports the encoded refs (e.g. /~1ssn, /~1a~0b) while ordinary names like c/d stay unchanged.

Adds EventProcessorPrivacyTest.allAttributesPrivateReportsEachNameAsTheReferenceThatNamesIt to assert the posted identify payload matches that behavior on the wire.

Reviewed by Cursor Bugbot for commit 1737441. Bugbot is set up for automated code reviews on this repo. Configure here.

…te names as references

java-sdk-internal 1.12.2 lists each attribute removed by allAttributesPrivate, or by redacting an anonymous context, as the attribute reference that names it. An attribute named /ssn is now reported as /~1ssn rather than /ssn, which reads back as the path to an attribute named ssn.

Co-authored-by: Cursor <cursoragent@cursor.com>
@abelonogov-ld
abelonogov-ld requested a review from a team as a code owner October 23, 2026 01:55
abelonogov-ld added a commit to launchdarkly/ios-client-sdk that referenced this pull request Oct 23, 2026
…ibutes (#544)

**Requirements**

- [x] I have added test coverage for new or changed functionality
- [x] I have followed the repository's [pull request submission
guidelines](../blob/v11/CONTRIBUTING.md#submitting-pull-requests)
- [ ] I have validated my changes against all supported platform
versions

**Related issues**

Stacked on `andrey/event-durability-tier1-buffer`, like #534, which this
follows up. Bugbot raised it on #538 ("All-private redaction names do
not reparse").

The Android counterpart is java-sdk-internal 1.12.2
([java-core#228](launchdarkly/java-core#228)),
which Android picks up in
[android-client-sdk#415](launchdarkly/android-client-sdk#415).

**Describe the solution you've provided**

`_meta.redactedAttributes` is a list of attribute references. When every
attribute is private (`allAttributesPrivate`, or an anonymous context in
a feature event), both encoders listed each attribute's raw name: the
`Codable` path in `LDContext.encodeSingleContext` and
`LDContextJSONWriter`. A name that starts with a slash, such as `/foo`,
reads back as the path to an attribute named `foo`, so the list named an
attribute other than the one that was removed. Since #534 looks
attribute names up literally, such an attribute reaches this branch.

Both encoders now list `Reference(literal: name).raw()`:

| Attribute name | Before | After |
| --- | --- | --- |
| `/foo` | `/foo` (the attribute `foo`) | `/~1foo` |
| `/a~b/c` | `/a~b/c` (invalid reference) | `/~1a~0b~1c` |
| `x/y`, `plain` | unchanged | unchanged |

Only names that start with a slash change. A name without one is already
a reference to itself. The Go SDK
(`ldattr.NewLiteralRef(key).String()`), the JavaScript SDKs
(`AttributeReference.redactionName`), and java-sdk-internal 1.12.2 write
the same form. Entries for attributes the application marked private
were already references and are unchanged.

`testAttributeNamesStartingWithASlashAreWrittenAndRedactedByName` now
expects the escaped names from both encoders. It also checks that every
listed entry, read back as a `Reference`, is valid and refers to an
attribute of the context. It fails against the previous code.

**Describe alternatives you've considered**

Escaping in each encoder by hand. `Reference(literal:)` already produces
the one-component path form for a leading slash, so both encoders share
it.

**Additional context**

Event output only. The unredacted encoding that `contextHash()` digests
does not list redacted attributes, so cached flags are unaffected.

Co-authored-by: Cursor <cursoragent@cursor.com>

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant