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
✨ [RUM-17990] add a path scrubber for serialized payloads - #240
Stack traces and URLs collected in Electron apps contain installation-specific paths (file:///Users/alice/…/app.asar/dist/main.js, C:\Users\alice\AppData\…). They prevent source maps from resolving, leak the user's home directory, and split aggregations per installation. This PR adds the component that replaces the app path in serialized payloads. It is not wired yet: the next PR in this stack injects it where payloads are written.
Changes
New PathScrubber (src/tools/pathScrubber.ts), created with await PathScrubber.init(): the app path (and its .unpacked folder) becomes /, so frames read /dist/main.js and match source maps uploaded with a /dist/ prefix.
It works on the serialized JSON, right before payloads are written, so every field of every payload type is covered. The app path compiles one regex matching its usual notations (raw path, Windows path, file:// URL).
A path is replaced wherever it appears, but never when glued to a longer file or folder name (MyApp2).
The main purpose is consistent paths for source maps. Masking the user's home directory is best effort, not exhaustive (data folders such as userData are not masked; the other known limits are listed in the class JSDoc). A false positive only costs misleading data, a miss leaves the path as is.
scrub() keeps valid JSON valid and never throws: on an internal error it returns its input and reports once.
Things to look at:
The regexes match the serialized JSON, with structural guards so a match never starts inside a JSON escape and the scan stays linear.
Covered by table-driven tests plus seeded property tests (random payloads stay valid JSON; near misses stay byte-identical).
Benchmark: a few ms to about 12 ms per 10 MB (budget: 50 ms), to be measured again under Electron's V8.
Test instructions
yarn vitest bench --run src/tools/pathScrubber.bench.ts: every case stays well under 50 ms
Read the it.each tables in src/tools/pathScrubber.spec.ts: each row is an input payload fragment and its scrubbed form
End-to-end checks come with the next PR, once the scrubber is wired into the payload writers
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.
POSIX paths and C:\... paths match the description: one regex per sdk path, longest match first, JSON stays valid and byte-identical off the match. Request changes. A UNC userData is kept at init and then left in the payload, with no skip error, so the home directory this component exists to remove still ships.
Customer impact:Low — PathScrubber has no production caller, so payloads stay as they are until a later PR calls scrub.
Concern
Serialized payload scrubbing
Risky
Quality — 3.0: POSIX and drive-letter paths are correct, and the tables, property checks, and linear-time test match that risk. The class JSDoc covers this internal type; there is no public API to document. One compiled regex per path, applied longest first on the serialized string, will take another notation or a new sdkPaths entry cleanly. The caller still has to pass plaintext JSON, including a replay segment before compression, because the on-disk replay batch is metadata plus base64. The UNC miss is what holds this at 3.0.
Review load — Focused (~30–45min): One risky boundary: which bytes scrub rewrites. Almost all of the time is pathScrubber.ts (notations, nested paths, JSON validity). The bench and coverage exclude belong to that same boundary. Windows matching landed in 2aa7793 and is the same boundary.
Findings
[Blocking] UNC paths are never scrubbed — src/tools/pathScrubber.ts:163 (2aa7793) sends \\server\\share\\... through the POSIX lookahead [/f], so a path whose JSON form starts with \ never matches and is never logged. Compile UNC like a drive path, and include the raw pattern's first character in the lookahead.
[Minor] Windows segment case stays in the payload — src/tools/pathScrubber.ts:166 (2aa7793) folds only the drive letter, and the near-miss table treats C:\\users\\... like a different path. Fold each segment, or confirm stacks always reuse app.getPath's casing.
[Nit] Scrub failure drops the thrown error — src/tools/pathScrubber.ts:79 wraps a fresh Error, so the one addError stack points at the catch. Pass the caught error through.
[Nit] Scrub failure drops the thrown error — src/tools/pathScrubber.ts:79 wraps a fresh Error, so the one addError stack points at the catch. Pass the caught error through.
The fixed message is deliberate. The caught error could carry part of the unscrubbed payload (e.g. a value in a TypeError message), which is what this component is meant to keep out of telemetry.
This is ready to merge. POSIX paths and Windows paths, including a different case, match the description: one regex per sdk path, longest first, valid JSON in and out. Approve. One file-URL encoding is still open, on the line below. e2e and integration were still running when I posted.
Customer impact:Low — PathScrubber has no production caller, so payloads stay as they are until a later PR calls scrub.
Concern
Serialized payload scrubbing
Risky
Quality — 4.5: The scrubber matches its contract on the paths I checked: raw stacks, forward-slash file URLs, nested crashDumps, and Windows case. The tables, property checks, and linear-time test cover that risk in proportion. The class JSDoc is the right doc for this internal type; there is no public API. One compiled regex per path, applied longest first, will take another notation or a new sdkPaths entry cleanly, and the next caller still has to pass plaintext JSON, including a replay segment before compression. The opposite-case non-ASCII file URL is what holds this below 5.0.
Review load — Focused (~30–45min): One risky boundary: which bytes scrub rewrites. Almost all of the time is pathScrubber.ts (notations, case, JSON validity) together with the tables that pin it. The bench and the coverage exclude sit on that same boundary. Windows matching is 79991d1.
Findings
[Minor] Opposite-case non-ASCII file URLs stay in the payload — src/tools/pathScrubber.ts:212 (79991d1) percent-encodes only the sdk path's own code point, so José does not match JOS%C3%89. Also encode that other simple case, or list it next to the %61 limit if nothing emits it.
This is ready to merge. PathScrubber replaces sdk paths in serialized JSON, the app path with / and data folders with <userData> / <crashDumps>, including the Windows notations, and it is not wired into the writers yet. Approve. The percent-encoded non-ASCII case limit is now in the class JSDoc, with the other limits. Integration was still running when I posted.
Customer impact:Low — PathScrubber has no production caller, so payloads stay as they are until a later PR calls scrub.
Concern
Serialized payload scrubbing
Risky
Quality — 5.0: The scrubber matches its contract: raw stacks, file URLs, nested crashDumps, and Windows case come out as the tables say, and a near miss stays byte-identical. Those tables, the property checks, and the linear-time test are proportionate to the regex. The class JSDoc keeps pace for this internal type; there is no public API to document. The design is sound: one compiled regex per path, longest first, will take another notation or a new sdkPaths entry. Wiring it later means passing plaintext JSON, including a replay segment before compression, since the on-disk replay batch is metadata plus base64.
Review load — Focused (~30–45min): One risky boundary: which bytes scrub rewrites. Almost all of the time is pathScrubber.ts (notations, case, JSON validity) together with the tables that pin it. The bench and the coverage exclude sit on that same boundary.
Please focus on issues likely to happen in real Electron apps. The main purpose is consistent paths for source maps; masking user paths is best effort, and its known limits are listed in the class JSDoc. Skip edge cases that need unlikely setups (unusual characters in install or data folder names, hand-crafted URLs, folders packagers never create), and don't raise again points already answered in resolved threads.
This is ready to merge. PathScrubber replaces sdk paths in serialized JSON, the app path with / and data folders with <userData> / <crashDumps>, including the Windows notations, and it is not wired into the writers yet. Approve. The named start constants on this head compile the same lookaheads as before. e2e and integration were still running when I posted.
Customer impact:Low — PathScrubber has no production caller, so payloads stay as they are until a later PR calls scrub.
Concern
Serialized payload scrubbing
Risky
Quality — 5.0: The scrubber matches its contract: raw stacks, file URLs, nested crashDumps, and Windows case come out as the tables say, and a near miss stays byte-identical. Those tables, the property checks, and the linear-time test are proportionate to the regex. The class JSDoc keeps pace for this internal type; there is no public API to document. The design is sound: one compiled regex per path, longest first, will take another notation or a new sdkPaths entry. Wiring it later means passing plaintext JSON, including a replay segment before compression, since the on-disk replay batch is metadata plus base64.
Review load — Focused (~30–45min): One risky boundary: which bytes scrub rewrites. Almost all of the time is pathScrubber.ts (notations, case, JSON validity) together with the tables that pin it. The bench and the coverage exclude sit on that same boundary.
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.
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
![cursor[bot]](https://avatars.githubusercontent.com/in/1210556?s=60&v=4){kind=small}
Motivation
Stack traces and URLs collected in Electron apps contain installation-specific paths (
file:///Users/alice/…/app.asar/dist/main.js,C:\Users\alice\AppData\…). They prevent source maps from resolving, leak the user's home directory, and split aggregations per installation. This PR adds the component that replaces the app path in serialized payloads. It is not wired yet: the next PR in this stack injects it where payloads are written.Changes
PathScrubber(src/tools/pathScrubber.ts), created withawait PathScrubber.init(): the app path (and its.unpackedfolder) becomes/, so frames read/dist/main.jsand match source maps uploaded with a/dist/prefix.file://URL).MyApp2).userDataare not masked; the other known limits are listed in the class JSDoc). A false positive only costs misleading data, a miss leaves the path as is.scrub()keeps valid JSON valid and never throws: on an internal error it returns its input and reports once.Things to look at:
Test instructions
yarn vitest bench --run src/tools/pathScrubber.bench.ts: every case stays well under 50 msit.eachtables insrc/tools/pathScrubber.spec.ts: each row is an input payload fragment and its scrubbed formChecklist