Skip to content

[FFLSDK-219] Preserve exposure deduplication across configuration key reordering - #400

Draft
typotter wants to merge 2 commits into
mainfrom
typo/fix-core-exposure-dedup-order
Draft

typotter wants to merge 2 commits into
mainfrom
typo/fix-core-exposure-dedup-order

Conversation

@typotter

Copy link
Copy Markdown
Collaborator

What changed

A browser-provider fingerprint fix with three regression cases.

  • Sort configuration object keys before hashing, including the rules flag map and nested precomputed JSON.
  • Preserve array ordering, retrieval-metadata exclusions, and the caller's original configuration and portable wire representation.

Why

Reloading equivalent configurations with reordered keys currently sends a duplicate exposure for the same assignment. Fixes FFLSDK-219, reproduced after #349 merged.

Potential risks

  • Existing cached exposures may be sent once again after upgrading if their previous fingerprint used a different key order.

How to verify

  • The first commit contains the unchanged-production reproduction: both ordering cases fail with two exposure requests instead of one; the 12 existing tracking tests pass.
  • A separate agent independently reproduced those failures using the repository's normal dependencies and test configuration, then reviewed the fix.
  • With the fix: all 23 browser suites / 335 tests pass, including nested JSON ordering, array-order sensitivity, nonmutation, and meaningful configuration changes.
  • Browser typecheck and full browser build pass; changed-file lint, formatting, and whitespace checks pass.

Impact

For end users, applications reloading equivalent flag configurations no longer send duplicate exposures solely because object keys arrive in a different order.

@linear-code

linear-code Bot commented Sep 23, 2026

Copy link
Copy Markdown

FFLSDK-219

@github-actions

Copy link
Copy Markdown

OpenFeature Browser Entrypoint Bundle Sizes

Measured from the Vite production output after installing packed @datadog/flagging-core and @datadog/openfeature-browser tarballs.

Entrypoint HTML JS Assets Raw JS Gzip JS Protobuf Markers
root provider smoke index.html 11 82.4 KiB 28.7 KiB no
precomputed configuration precomputed.html 6 6.0 KiB 2.8 KiB no
rules-based configuration protobuf.html 13 174.7 KiB 54.9 KiB yes

Default and precomputed entrypoints are expected to keep Protobuf-ES out of their bundles. Rules-based entrypoints are expected to include protobuf markers as a positive control. The marker check is a packed-artifact backstop; the source import boundary is enforced by packages/core/test/entrypoint-boundaries.spec.ts.

OpenFeature Browser Tracking Hook Bundle Sizes

Synthetic entrypoints import and call tracking hook factories from the packed @datadog/openfeature-browser/rules-based ESM package. Deltas are measured against the no-hook baseline from the same Vite production build.

Scenario HTML JS Assets Raw JS Raw Δ Gzip JS Gzip Δ
tracking hook baseline tracking-baseline.html 5 2.4 KiB 0 B 1.4 KiB 0 B
exposure logging hook tracking-exposure.html 10 39.7 KiB +37.3 KiB 15.6 KiB +14.2 KiB
evaluation logging hook tracking-evaluation.html 10 37.2 KiB +34.8 KiB 14.8 KiB +13.4 KiB
RUM tracking hook tracking-rum.html 8 4.8 KiB +2.4 KiB 2.7 KiB +1.3 KiB
all tracking hooks tracking-all.html 12 43.8 KiB +41.4 KiB 17.4 KiB +16.1 KiB

This report shows current PR artifact sizes only; it does not compare against the base branch.

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