Skip to content

feat: Obfuscate potential PII in logs#1219

Open
jaissica12 wants to merge 15 commits intodevelopmentfrom
feat/SDKE-889-logger-obfuscate-data-v2
Open

feat: Obfuscate potential PII in logs#1219
jaissica12 wants to merge 15 commits intodevelopmentfrom
feat/SDKE-889-logger-obfuscate-data-v2

Conversation

@jaissica12
Copy link
Contributor

@jaissica12 jaissica12 commented Mar 20, 2026

Background

The Logger currently outputs raw batch and event payloads at various log levels (error, warning, verbose). These payloads can include Personally Identifiable Information (PII)—data that can identify or be reasonably linked to an individual, such as email addresses, phone numbers, names, user IDs, IP addresses, or other user-level identifiers.

What Has Changed

  • Adds obfuscateData method to be used when logging payloads
  • Updates logger calls to to use obfuscateData method when passing in payloads that may contain PII
  • Updates identity calls to target matched_identities payload for obfuscation, while allowing the rest of the identity payload to be visible for debugging
  • Removes Logger from Vault to avoid spamming verbose logs

Screenshots/Video

  • {Include any screenshots or video demonstrating the new feature or fix, if applicable}

Checklist

  • I have performed a self-review of my own code.
  • I have made corresponding changes to the documentation.
  • I have added tests that prove my fix is effective or that my feature works.
  • I have tested this locally.

Additional Notes

  • {Any additional information or context relevant to this PR}

Reference Issue (For employees only. Ignore if you are an outside contributor)


Note

Medium Risk
Changes logging behavior for event/batch/identity payloads and adds new storage error handling paths; while intended to be safe, it touches batching/upload and identity flows where regressions could impact observability or offline persistence.

Overview
Reduces the chance of leaking PII via logs by introducing utils.obfuscateData/obfuscateDevData and using them when verbose-logging event payloads, batch uploads, Rokt placement attributes/queued payloads, and (in production mode) matched_identities in Identity API responses.

Hardens persistence writes by removing Vault-internal logging, simplifying Vault constructors (no injected logger), and wrapping non-critical store() calls (events/batches offline queues, identity cache, foreground time tracker) in try/catch so storage failures don’t break SDK execution; also updates tests accordingly and documents the new PII logging guideline in AGENTS.md.

Written by Cursor Bugbot for commit 642471a. This will update automatically on new commits. Configure here.

@jaissica12 jaissica12 force-pushed the feat/SDKE-889-logger-obfuscate-data-v2 branch from 6c5f222 to 12d4648 Compare March 20, 2026 14:23
@jaissica12 jaissica12 marked this pull request as ready for review March 20, 2026 14:25
@jaissica12 jaissica12 requested a review from a team as a code owner March 20, 2026 14:25
Copy link
Collaborator

@alexs-mparticle alexs-mparticle left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

vault.ts: Remove the try/catch from store() — let errors propagate to callers.

The vault should be a dumb wrapper around the Storage API. Right now there's a conflict:

  1. vault.ts catches the error internally and logs via console.error
  2. Callers in batchUploader.ts and identity-utils.ts wrap .store() in their own try/catch with Logger.error()

Since the vault swallows the error, the callers' try/catches are dead code — the error never reaches them.

Suggestion: remove the try/catch (and the console.error) from BaseVault.store() entirely. Let the raw setItem error propagate so callers can handle it with proper Logger calls as they're already set up to do.

Copy link
Collaborator

@alexs-mparticle alexs-mparticle left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit: Inconsistent Logger access in batchUploader.ts

The new error handling code accesses the logger three different ways in the same file:

  • const { Logger } = this.mpInstance;Logger.error(...) (in queueEvent)
  • this.mpInstance.Logger.error(...) (in prepareAndUpload)
  • logger.error(...) via parameter (in uploadBatches)

They all resolve to the same instance logger, so this is just a style nit — but it'd be cleaner to pick one approach consistently within the new code.

@cursor
Copy link

cursor bot commented Mar 20, 2026

PR Summary

Medium Risk
Changes verbose logging across batch upload, identity, and Rokt flows and removes Vault storage try/catch/logging, which could alter behavior when Storage is unavailable or full. Also expands the SDKLoggerApi contract (isVerbose()), requiring downstream loggers/mocks to implement it.

Overview
Reduces production PII exposure by adding utils.obfuscateData/obfuscateDevData and switching verbose payload logging to emit raw data only in development mode (otherwise logging type-shaped, obfuscated structures).

Applies this to event/batch logging in BatchUploader, developer-supplied attributes/queued message payloads in RoktManager, and selectively obfuscates matched_identities when verbose-logging identity responses.

Simplifies storage vaults by removing injected logger support and all internal verbose/error logging/try-catch in vault.ts, updates Logger/SDKLoggerApi with isVerbose(), and adjusts tests/mocks accordingly.

Written by Cursor Bugbot for commit 3b5cf5a. This will update automatically on new commits. Configure here.

Copy link

@cursor cursor bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Cursor Bugbot has reviewed your changes and found 1 potential issue.

Fix All in Cursor

Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, have a team admin enable autofix in the Cursor dashboard.

try {
this.eventVault.store(this.eventsQueuedForProcessing);
} catch (error) {
this.mpInstance.Logger.error('Failed to store events to offline storage. Events will remain in memory queue.');
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's remove this try/catch block and error. it's unnecessary.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, that makes sense. Removed

try {
this.eventVault.store([]);
} catch (error) {
this.mpInstance.Logger.error('Failed to clear events from offline storage.');
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we can remove these try catches as well

// Clear batch queue since everything should be in Offline Storage
this.batchesQueuedForProcessing = [];
} catch (error) {
this.mpInstance.Logger.error('Failed to store batches to offline storage. Batches will remain in memory queue.');
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Remove this try/catch

try {
this.timerVault.store(Math.round(this.totalTime));
} catch (error) {
// Time tracking persistence is not critical for SDK functionality
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Remove try/catch block

try {
idCache.store(cache);
} catch (error) {
// Silently fail - identity caching is an optimization, not critical for functionality
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Remove try/catch

@sonarqubecloud
Copy link

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants