[RUM-13793] 🐛 Skip potential sanitize updates on unaltered fields

[bdibon]

Motivation

When a RumResourceEvent has a resource.url field that is too long one of two things can happen:

1. beforeSend is used: the sanitize() function will return undefined and the limitModification function will set the resource.url field to undefined, effectively deleting it. This caused problem on web-ui (now fixed).

2. beforeSend is not used: the createBatch() function will discard the message that contains the RumResourceEvent, we're loosing data.

---

Reflection behind the changes

What do we even fix?

Sending invalid data

The problem that surfaced to our users is now fixed, web-ui doesn't break when a RumResourceEvent has no resource.url.

The SDK shouldn't send invalid data to intake, this can be fixed in several ways:

• For the specific resource.url field we can simply truncate it instead of setting it to undefined, then "how much do we truncate?", at lest enough for the message to intake to not be discarded
• Have a generic fix that replaces every field sanitized to undefined by either "" or {}

Inconsistent behavior

Also note the SDK is behaving in an inconsistent manner:

• if you don't pass a beforeSend() in the RumInitConfiguration, events with unsafe fields (large URL for example) will be discarded by the transport layer. The event is discarded
• if you do pass a beforeSend() that doesn't alter the event, unsafe fields will be sanitized, which mean they will be either set to undefined (string too long), or truncated (the object is too big); The event or context is updated while the user never intended to do it.

Summary

Then we have two problems to solve:

1. invalid data sent to intake
2. inconsistent behavior with beforeSend(),

We solve 1. by not erasing required fields.

We solve 2. by not applying the sanitize process to fields the user hasn't modified, this requires us to compare the original value object[field] with the new value in setNestedValue(). This is easy for string values, but the implementation might be more involved for objects and potentially slow.

For this PR, I've have decided to fix 1 completely and 2 partially.

For string values, we don't go through the sanitize process if they didn't change.

For object values, we still go through it, at the risk of tempering the value if it's a large object (serialization wise), meaning the resulting object might be truncated. I think this is an acceptable outcome given the low probability of occurence (objects whose serialized version length is superior to 225 280 characters).

Changes

After second feedback round:

• Skip sanitize() calls for untouched string values
• Add a related unit test

Changes history

After first feedback round:

• When a field is erased by the sanitize function, just replace it with "" or {} depending on the fieldType
• Add a related unit test

Before feedback:

• Save resource.url before beforeSend runs, so the original value can be restored if the user callback corrupts it
• Truncate resource.url to 32 KiB if it exceeds that limit (or was set to undefined by beforeSend), with a display.warn message
• Add two unit tests in assembly.spec.ts covering truncation both with and without a beforeSend callback.

Test instructions

• Manual test (use the sandbox):

<script>
  fetch('/' + 'a'.repeat(300_000))
</script>

• Unit tests:

yarn test:unit --spec 'packages/rum-core/src/domain/limitModification.spec.ts'

Checklist

• Tested locally
• Tested on staging
• Added unit tests for this change.
• Added e2e/integration tests for this change.
• Updated documentation and/or relevant AGENTS.md file

[cit-pr-commenter-54b7da]

Bundles Sizes Evolution

📦 Bundle Name	Base Size	Local Size	𝚫	𝚫%	Status
Rum	174.53 KiB	174.54 KiB	+19 B	+0.01%	✅
Rum Profiler	6.16 KiB	6.16 KiB	0 B	0.00%	✅
Rum Recorder	27.46 KiB	27.46 KiB	0 B	0.00%	✅
Logs	56.84 KiB	56.84 KiB	0 B	0.00%	✅
Flagging	944 B	944 B	0 B	0.00%	✅
Rum Slim	130.21 KiB	130.23 KiB	+19 B	+0.01%	✅
Worker	23.63 KiB	23.63 KiB	0 B	0.00%	✅

🚀 CPU Performance

Action Name	Base CPU Time (ms)	Local CPU Time (ms)	𝚫%
RUM - add global context	0.0047	0.0058	+23.40%
RUM - add action	0.0183	0.0163	-10.93%
RUM - add error	0.0147	0.0171	+16.33%
RUM - add timing	0.0032	0.0034	+6.25%
RUM - start view	0.0134	0.0162	+20.90%
RUM - start/stop session replay recording	0.0008	0.0009	+12.50%
Logs - log message	0.0197	0.0182	-7.61%

🧠 Memory Performance

Action Name	Base Memory Consumption	Local Memory Consumption	𝚫
RUM - add global context	26.88 KiB	27.00 KiB	+122 B
RUM - add action	51.21 KiB	52.47 KiB	+1.26 KiB
RUM - add timing	26.72 KiB	27.53 KiB	+828 B
RUM - add error	56.25 KiB	53.87 KiB	-2.38 KiB
RUM - start/stop session replay recording	25.88 KiB	26.30 KiB	+430 B
RUM - start view	452.02 KiB	448.74 KiB	-3.28 KiB
Logs - log message	45.00 KiB	44.44 KiB	-566 B

🔗 RealWorld

[datadog-datadog-prod-us1]

✅ Tests

🎉 All green!

❄️ No new flaky tests detected
🧪 All tests passed

🎯 Code Coverage (details)
• Patch Coverage: 66.67%
• Overall Coverage: 77.19% (-0.01%)

_{This comment will be updated automatically if new data arrives.
🔗 Commit SHA: 5fa77a1 | Docs | Datadog PR Page | Was this helpful? React with 👍/👎 or give us feedback!}

[bdibon]

/to-staging

[gh-worker-devflow-routing-ef8351]

View all feedbacks in Devflow UI.

2026-03-12 13:41:02 UTC ℹ️ Start processing command /to-staging

---

2026-03-12 13:41:08 UTC ℹ️ Branch Integration: starting soon, merge expected in approximately 17m (p90)

Commit 5fa77a13ce will soon be integrated into staging-11.

---

2026-03-12 13:56:24 UTC ℹ️ Branch Integration: this commit was successfully integrated

Commit 5fa77a13ce has been merged into staging-11 in merge commit b57398e161.

Check out the triggered DDCI request.

If you need to revert this integration, you can use the following command: /code revert-integration -b staging-11