feat: Add optional support for per-context summary events.

[kinyoklion]

Note

Medium Risk
Touches core analytics event buffering/flush and JSON output paths; enabling per-context summarization changes payload shape/volume and includes context data in summary events, so regressions could affect event delivery and privacy expectations.

Overview
Adds an optional per-context summarization mode that can emit multiple summary events per flush (one per LDContext) instead of a single aggregated summary.

Refactors the event pipeline to use a new EventSummarizerInterface with AggregatedEventSummarizer (backward-compatible default) and PerContextEventSummarizer, extends EventsConfiguration with a perContextSummarization flag, and updates DefaultEventProcessor/EventOutputFormatter to send/restore a list of summaries and to include serialized context in summary output when present. Tests are updated and a comprehensive PerContextEventSummarizerTest is added.

^{Written by Cursor Bugbot for commit 3a0f579. This will update automatically on new commits. Configure here.}

[kinyoklion]

bugbot review

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

[cursor]

Using LDContext as HashMap key causes incorrect grouping

Medium Severity

PerContextEventSummarizer uses LDContext as a HashMap key, but LDContext.equals()/hashCode() compare all attributes (name, anonymous, custom attributes, private attributes), not just identity (kind + key). Two contexts representing the same user but with different attribute values would produce separate summaries instead of being grouped together. Additionally, LDContext.hashCode() is explicitly documented as inefficient and "not an anticipated or recommended use case" for map keys. The existing ServerSideEventContextDeduplicator demonstrates the correct pattern: keying by getFullyQualifiedKey().

Additional Locations (1)

• lib/shared/internal/src/main/java/com/launchdarkly/sdk/internal/events/PerContextEventSummarizer.java#L84-L93

 

[kinyoklion]

This is describing the correct behavior. We want summaries grouped by their exact context accounting for all attributes.

The performance isn't a concern for this use-case. (Even then the performance of this is actually fine given the number of attributes contexts have in practice.)