🎨 [PANA-4929] Add the concept of serialization transactions and reorganize state

[sethfowler-datadog]

Motivation

The next PR in this series will introduce support for an experimental second session replay serialization code path into the code base. To make this process smoother, it will be helpful to have a couple of basic abstractions in place:

1. We should create a home for state which is shared between a sequence of related records. The new serialization algorithm will have different rules for when this kind of state should be reset; by creating an explicit place for this state to live, we make that easier to get right.
2. We should migrate to a builder-like pattern for the contents of DOM serialization records. The new serialization algorithm will derive more benefit from this, since it has more central post-processing work that must be performed, but it's useful even for the current one, and using the same patterns for both will make it easier to share code.

The first abstraction was already added in #3887; this PR builds on that work. The second abstraction is new in this PR.

Changes

Added: SerializationTransaction

• A new SerializationTransaction type has been added. It holds builder-like methods and ephemeral state that lives only during a specific serialization operation. This is effectively a replacement for the old SerializeOptions type, which has been removed.
• SerializationTransaction has been threaded through the serialization code; function arguments have been reworked where needed.
• Code that performs serialization (e.g. startFullSnapshots(), trackMutations()) now wraps that serialization work in the new serializeInTransaction() function, which creates a SerializationTransaction and handles other bookkeeping before handing things off to the existing code to perform the real work.

Enhanced: RecordingScope (formerly SerializationScope)

• SerializationScope has been renamed to RecordingScope.
• State that used to live on the old SerializationContext type has been migrated onto RecordingScope. SerializationContext has been removed.
• Quite a bit of other state has also been moved onto RecordingScope. This includes the old RecordIds type, which has been renamed to EventIds since it's used to assign ids to events.
• RecordingScope has been threaded through much of the recording code, including all of the trackers.

These changes conclude the preliminary refactoring for the new serialization code path; future PRs will focus on the new code path itself.

Test instructions

This PR is a pure refactoring PR that affects only the recording code for session replay. To test it, it's enough to test session replay itself.

Checklist

• Tested locally
• Tested on staging (will test after code freeze)
• Added unit tests for this change.
• Added e2e/integration tests for this change.

[cit-pr-commenter]

Bundles Sizes Evolution

📦 Bundle Name	Base Size	Local Size	𝚫	𝚫%	Status
Rum	164.13 KiB	164.12 KiB	-1 B	-0.00%	✅
Rum Profiler	4.84 KiB	4.84 KiB	0 B	0.00%	✅
Rum Recorder	19.62 KiB	19.74 KiB	+123 B	+0.61%	✅
Logs	55.91 KiB	55.91 KiB	0 B	0.00%	✅
Flagging	944 B	944 B	0 B	0.00%	✅
Rum Slim	121.39 KiB	121.39 KiB	0 B	0.00%	✅
Worker	23.63 KiB	23.63 KiB	0 B	0.00%	✅

🚀 CPU Performance

Pending...

🧠 Memory Performance

Action Name	Base Memory Consumption	Local Memory Consumption	𝚫
RUM - add global context	25.98 KiB	25.46 KiB	-533 B
RUM - add action	49.38 KiB	47.54 KiB	-1.84 KiB
RUM - add timing	24.28 KiB	25.24 KiB	+977 B
RUM - add error	54.03 KiB	51.73 KiB	-2.31 KiB
RUM - start/stop session replay recording	23.74 KiB	24.38 KiB	+661 B
RUM - start view	427.50 KiB	426.46 KiB	-1.03 KiB
Logs - log message	44.19 KiB	43.81 KiB	-385 B

🔗 RealWorld

[datadog-datadog-prod-us1]

✅ Tests

🎉 All green!

❄️ No new flaky tests detected
🧪 All tests passed

🎯 Code Coverage
• Patch Coverage: 98.81%
• Total Coverage: 92.67% (+0.00%)

View detailed report

_{This comment will be updated automatically if new data arrives.
🔗 Commit SHA: 88a5f23 | Docs | Datadog PR Page | Was this helpful? Give us feedback!}