🔊 Report remote configuration sync metadata on configuration telemetry

[mormubis]

Motivation

The remote configuration telemetry RFC wants to measure how long a published config takes to take effect on a device. Two segments: last_synced - last_modified for CDN to fetch, and first_applied - last_synced for fetch to apply. We have no visibility on either today.

The schema already merged in the events format repo and is synced here. This is the browser side.

Changes

The metadata goes in the existing dd_rc_<id> localStorage entry instead of a separate key, so a version and its metadata can't drift apart on a partial write. CACHE_VERSION is bumped to 3 and fetchedAt becomes a metadata object with lastModified, lastSynced, firstApplied and syncId.

sync_id doesn't follow the RFC. The RFC regenerates it on non-304 fetches, but we send no If-None-Match and never see a 304. Instead write() compares the fetched payload with the cached one and skips the write when they match. It keys on the config changing instead of the transport, and it's also what keeps firstApplied from being wiped by a background refetch.

The metadata is threaded through doInit into serializeRumConfiguration instead of module state. RUM and Logs read the same cache entry once #4884 lands, so a singleton would report the wrong product's numbers.

config_id is not included, we already send remote_configuration_id. version_id is not included either, x-amz-version-id is not readable from JS.

Nothing is reported on the sync path (sync: true or the legacy remoteConfigurationId). Fetch and apply happen in the same tick there, so first_applied - last_synced would always be ~0. I can add it if you prefer having the CDN to fetch half for those setups. What do you think?

Test instructions

Needs a real published remote configuration ID.

1. yarn dev-server start
2. Add a sandbox page with remoteConfiguration: { id: '<rc-id>' }, proxy: '/proxy', telemetrySampleRate: 100 and telemetryConfigurationSampleRate: 100
3. Load it once. localStorage.getItem('dd_rc_<rc-id>') has version: 3 and a metadata with lastModified, lastSynced and syncId, no firstApplied yet
4. Load it again. firstApplied is set, lastSynced and syncId unchanged
5. agent-browser tab new to flush, then yarn dev-server intake telemetry-configuration-events | jq '.telemetry.configuration.remote_configuration'

First load reports nothing, second reports the four fields:

{"last_modified":1777557229000,"last_synced":1787930428705,
 "first_applied":1787930438546,"sync_id":"476d2ee9-fb31-4c30-824a-5410d4850ad0"}

Checklist

• Tested locally
• Tested on staging
• Added unit tests for this change.
• Added e2e/integration tests for this change. The existing e2e seeds the cache and checks config application, not telemetry. The two page load flow plus sampling makes it awkward, I'd rather do it separately.
• Updated documentation and/or relevant AGENTS.md file

[mormubis]

This early return is the whole sync_id semantic, and it's also what keeps firstApplied from being wiped when the background fetch pulls the same config back. Worth knowing before touching the comparison.

[mormubis]

last-modified is the only useful header we can read here. etag and x-amz-version-id are not CORS-safelisted and the CDN doesn't send Access-Control-Expose-Headers, so they come back null in the browser even though curl sees them. That's why there's no version_id in this PR.

[mormubis]

doBackgroundCacheSync starts the fetch before this line, so it looks racy. It isn't, the stamp is synchronous and the fetch can't resolve before the next microtask. I left the order alone to keep the diff small, but I can move the sync call below if it reads better.

[cit-pr-commenter-54b7da]

Bundles Sizes Evolution

📦 Bundle Name	Base Size	Local Size	𝚫	𝚫%	Status
Rum	182.02 KiB	182.86 KiB	+852 B	+0.46%	✅
Rum Profiler	8.43 KiB	8.43 KiB	0 B	0.00%	✅
Rum Recorder	25.32 KiB	25.32 KiB	0 B	0.00%	✅
Logs	57.96 KiB	57.96 KiB	0 B	0.00%	✅
Rum Salesforce	N/A	140.90 KiB	N/A	N/A	N/A
Rum Slim	140.08 KiB	140.90 KiB	+838 B	+0.58%	✅
Worker	22.96 KiB	22.96 KiB	0 B	0.00%	✅
Rum Shopify	N/A	207.65 KiB	N/A	N/A	N/A
Rum-shopify Profiler	N/A	8.43 KiB	N/A	N/A	N/A
Rum-shopify Recorder	N/A	3.74 KiB	N/A	N/A	N/A

[datadog-datadog-prod-us1]

✅ All CI checks and tests passed.

🎉 All green!

🧪 All tests passed
❄️ No new flaky tests detected

🎯 Code Coverage (details)
• Patch Coverage: 74.07%
• Overall Coverage: 76.99% (-0.02%)

_{This comment will be updated automatically if new data arrives.
🔗 Commit SHA: 9febebe | Docs | View more details | Give us feedback!}