[btthomas]

Motivation

Prototype browser onboarding diagnostics without requiring RUM, using the SDK diagnostic v1 contract in ddoghq/dd-source#98932. The previous draft sent per-transition events that the current backend rejects.

Changes

• Send one sdk_initialization report when initialization settles: ready, failed, or cached_fallback, with the matching error code and measured milestones.
• Send at most one non-final incomplete snapshot on page exit/provider close while initialization is pending. There is no observation timer or sequence field. If a page resumes and initialization completes, the settled result preserves runtime ID/start time and takes precedence. An indefinitely pending attempt without a usable exit notification may produce no report.
• Reserve provider_error / CONFIG_FETCH_FAILED for configuration failures after initialization settles, once per runtime.
• Reuse the existing /api/v2/flagevaluation endpoint and browser batch/HTTP helpers. Diagnostics and genuine evaluations now share one text/plain JSONL batch. Each diagnostic envelope has type: "sdk_diagnostic", schema_version: 1, and payload. Existing transport limits apply; diagnostic-only 2 KiB/32-record restrictions are removed.
• Flush pending evaluation aggregates and diagnostics together on close and before the page-exit transport flush. Standalone evaluation hooks keep their existing transport ownership.
• Preserve ordinary evaluation behavior, identity/environment validation, and optional local debugMode console output. Diagnostic uploads remain independent of debugMode and do not include credentials, flag values, targeting context, or arbitrary error messages.
• Validate serialized requests against a pinned copy of the canonical backend schema. Update the harness smoke assertions and experiment documentation. AI-assisted implementation.

Validation

• 456 browser unit tests pass, including canonical schema, no timed snapshots, cached fallback, page-exit/close, and existing evaluation regressions.
• Browser typecheck, package builds, changed-file Biome checks, and git whitespace checks pass.
• 17 Chromium smoke tests pass against the packaged SDK, including actual endpoint/content-type/JSONL assertions, slow initialization, evaluation while uploads fail with debugMode off/on, and mixed-batch requests on close and simulated page exit.
• Live staging intake, persistence, and querying remain unverified. These tests use intercepted HTTP requests; HTTP acceptance alone would not prove storage. Enable diagnostic traffic only after the backend scope, fields, and diagnostic gates are ready.

Checklist

• Updated documentation
• Tested locally
• Tested on staging
• Added unit tests for this change
• Added e2e/integration tests for this change

[github-actions]

OpenFeature Browser Provider Bundle Sizes

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

Both scenarios initialize an OpenFeature provider, evaluate a boolean flag, change context, and evaluate again. Telemetry is disabled for DatadogProvider; no tracking hooks are registered for DatadogCoreProvider. DatadogProvider fetches precomputed assignments for each context; DatadogCoreProvider receives rules from fetchRulesConfiguration once and evaluates locally.

Sizes include OpenFeature and the same small scenario harness. Configuration responses are supplied by Playwright and are not bundled. These are complete scenario JS sizes, not configuration payload sizes or isolated provider/Protobuf costs; the difference between rows is not a decoder-only delta.

Scenario	HTML	JS Assets	Raw JS	Gzip JS	Protobuf Markers
DatadogProvider (precomputed fetching)	provider.html	19	101.5 KiB	37.2 KiB	no
DatadogCoreProvider + fetchRulesConfiguration	core-provider.html	15	165.1 KiB	51.7 KiB	yes

Dependency checks passed: no Protobuf markers in default/precomputed scenarios; markers present in rules-based scenarios.

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	6	2.7 KiB	0 B	1.6 KiB	0 B
exposure logging hook	tracking-exposure.html	14	65.3 KiB	+62.6 KiB	24.8 KiB	+23.2 KiB
evaluation logging hook	tracking-evaluation.html	14	61.8 KiB	+59.1 KiB	23.5 KiB	+21.9 KiB
RUM tracking hook	tracking-rum.html	10	6.8 KiB	+4.1 KiB	3.7 KiB	+2.1 KiB
all tracking hooks	tracking-all.html	17	69.8 KiB	+67.1 KiB	26.9 KiB	+25.3 KiB

OpenFeature Node Server Bundle Sizes

Independent Webpack production builds of the installed core and Node SDK tarballs, targeting Node 18 with ESM (module export condition). Node built-ins remain external. OpenFeature, dd-trace, and configuration fixtures are not bundled.

Scenario	Raw JS	Gzip JS	Protobuf Modules
Node provider only	39.1 KiB	12.5 KiB	no
SSR helpers only (fetch client rules + serialize)	80.8 KiB	23.4 KiB	yes
Node provider + SSR helpers	118.8 KiB	34.7 KiB	yes

Adding SSR helpers to the provider adds 79.7 KiB raw / 22.2 KiB gzip in this build. This includes fetching, parsing, and serialization, not just the decoder. SSR helpers fetch rules for the browser, not for configuring that provider (which uses its existing JSON API).

These are bundler sizes, not npm install sizes, unbundled Node require/import costs, payload sizes, or latency. Gzip compares compressed artifacts. The browser scenarios include OpenFeature and a different harness, so their sizes are not directly comparable.

Dependency checks passed: no Protobuf runtime or generated schema modules in the provider-only bundle; present in both SSR bundles (checked using Webpack module statistics).

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