You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
✨ Persist tracking consent for crash recovery - #233
A crash is reported at the next launch, with the session, view and customer context saved before it happened. That context does not show whether the crash was captured with consent, so a crash from a refused or undecided period could be sent once tracking is granted again. Part of RUM-15526.
Changes
Persisted consent history: TrackingConsentManager stores its timestamped history in a DiskValueHistory, like the session and view histories.
Assembly check: a RUM format hook discards events whose start time falls in a refused period, or outside the known history. A pending period takes the decision that ended it; events of a period still undecided are left to the batch storage.
Restart: a pending period left undecided by the previous process is recorded as refused, as its pending batches are deleted at startup.
Recovered crashes: no specific handling. They go through the same check, then are stored according to the current consent like other events.
Consent changes are still written asynchronously: a crash right after a refusal, before it reaches disk, is accepted at the next launch.
Test instructions
yarn vitest run
yarn tsc -p src --noEmit
yarn test:e2e: the crash scenarios cover restart recovery with the default granted consent.
Checklist
Tested locally (playground)
Added unit tests for this change.
Added e2e/integration tests for this change.
Updated related documentation.
Agentic code review findings addressed or explicitly dismissed.
Approve. Pending context stays in memory, refusal restores the last authorized snapshot, and a grant writes that history with the refused interval left empty. Existing session, view, and customer-context storage is unchanged on this branch.
Customer impact:Low — DiskValueHistory still records session, view, and customer context on every change. Nothing calls ContextHistoryFactory, so this history is written only after a later change constructs it.
Concern
Consent transitions, refusal rollback, and restart
Risky
Ordered JSON disk writes
Routine
Quality — 5.0: The transitions are correct: leaving granted closes the active entry and snapshots it before a pending value is reopened in memory, and refusal puts that snapshot back. Tests match the risk — same-timestamp refusal and grant, restart with the previous process's value closed, collector ordering, and a serialization failure isolated to one history — and DiskStorage covers ordered writes and a failed write. The architecture section states this contract. The design holds up: one factory subscription updates every history before later collectors run, which is the boundary session and view wiring can build on.
Review load — Focused (~30min–1h): The risky read is the consent state machine and what survives refusal or restart. The disk queue is a short routine piece in the same style as DiskValueHistory. Both sit in ✨ Add consent-aware context history.
This is a correct, well-tested slice, and I would merge it as-is. TrackingConsentHistory keeps undecided changes in memory, writes them on grant, and on refusal restores the last authorized snapshot, including the same-timestamp and previous-process cases. ContextHistoryFactory applies that transition for every history before a later subscriber runs. GitLab e2e and integration were still running when I posted. Approve.
Customer impact:Low — init still records session, view, and customer context through DiskValueHistory. These types affect disk and events only once a later change constructs ContextHistoryFactory.
Concern
Consent-aware context history (transitions, snapshot persistence, subscription order)
Risky
Quality — 5.0: The transition rules match the consent model in the description and in docs/ARCHITECTURE.md: a refusal leaves the refused interval empty, a grant keeps the latest configured value for the new period, and a restart leaves the previous process out of the current context. The factory specs cover grant, refusal, same-timestamp boundaries, a consent change during load, and a serialization failure on one history while another still commits; DiskStorage covers ordered snapshots and a failed write. The split is sound: DiskStorage is only a JSON queue, TimeStampValueHistory stays the interval index, and the factory owns the single consent subscription so a collector cannot observe a half-applied transition.
Review load — Focused (~30–45min): One risky boundary: which intervals are authorized, which stay in memory, and the guarantee that every history has applied the transition before a collector callback. The write queue and replaceEntries belong to that same behavior. The one commit carries the whole boundary.
Persist the consent history like the session and view histories, and
discard RUM events whose start time falls in a refused or unknown
period. A pending period takes the decision that ended it, and a period
left undecided by the previous process counts as refused.
Recovered crashes no longer need a dedicated check or storage override:
they are stored according to the current consent like other events.
The reason will be displayed to describe this comment to others. Learn more.
Treat malformed consent history as absent
When _dd_tracking_consent_history contains syntactically valid JSON such as [null], this new call reaches DiskValueHistory.init(), whose restore loop dereferences entry.endTime outside its read/parse try block (src/tools/DiskValueHistory.ts:49-55). The resulting exception rejects the top-level SDK init() instead of falling back to an empty consent history. The current revision therefore retains the earlier malformed-history failure through the newly introduced DiskValueHistory path even though the intermediate TrackingConsentHistory implementation is gone; validate restored entries or catch restoration errors before constructing the manager.
The reason will be displayed to describe this comment to others. Learn more.
Await the initial consent snapshot before returning
On a fresh launch, constructing the manager only queues the initial consent snapshot through DiskValueHistory.add(); this method returns before its fs.writeFile promise settles, and init() provides no flush before returning. If the native process crashes shortly after the SDK reports successful initialization, the history file can still be missing or incomplete, so the next launch finds no consent interval covering that crash and discards the recovered report. Await the initial snapshot before completing initialization so the crash-recovery feature is effective immediately.
The reason will be displayed to describe this comment to others. Learn more.
Rotate pre-init renderer views when consent history starts
When the Browser RUM SDK is already running in a window before a deferred main-process init(), the active renderer view keeps a date from before this manager was created. RendererPipeline passes that unchanged date as startTime for every later update of the view, so this callback finds no covering consent entry and discards every update even after initialization; meanwhile post-init actions and errors can still be uploaded with that view ID, leaving them attached to a view document that never arrives until navigation or session renewal creates a new view. The documented pre-init bridge supports such existing windows, so initialization needs to rotate/rebase their active views or otherwise establish a consent boundary they can use.
Useful? React with 👍 / 👎.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
![cursor[bot]](https://avatars.githubusercontent.com/in/1210556?s=60&v=4){kind=small}
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
Motivation
A crash is reported at the next launch, with the session, view and customer context saved before it happened. That context does not show whether the crash was captured with consent, so a crash from a refused or undecided period could be sent once tracking is granted again. Part of RUM-15526.
Changes
TrackingConsentManagerstores its timestamped history in aDiskValueHistory, like the session and view histories.pendingperiod takes the decision that ended it; events of a period still undecided are left to the batch storage.pendingperiod left undecided by the previous process is recorded as refused, as its pending batches are deleted at startup.Consent changes are still written asynchronously: a crash right after a refusal, before it reaches disk, is accepted at the next launch.
Test instructions
yarn vitest runyarn tsc -p src --noEmityarn test:e2e: the crash scenarios cover restart recovery with the defaultgrantedconsent.Checklist