SDK tracking ID helpers throw when Web Storage is unavailable

[notsomeonebutnoone]

Describe the bug

The public SDK helpers getAnonymousId() and getSessionId() read from localStorage and sessionStorage without handling storage access errors.

Web Storage access can throw a DOMException such as SecurityError when storage is restricted by browser settings or unavailable in a sandboxed context. When this happens, these helpers throw instead of treating the tracking ID as unavailable.

The error also propagates through:

• getTrackingIds()
• getTrackingParams()

This differs from getProfileId(), which already catches storage errors and returns null.

This can affect user-facing flows that treat tracking information as optional metadata. For example, Stripe checkout metadata and contact-form submission both call getTrackingIds().

To Reproduce

1. Load @databuddy/sdk in a browser.
2. Override storage reads to simulate a restricted-storage environment:

const originalGetItem = Storage.prototype.getItem;

Storage.prototype.getItem = function () {
	throw new DOMException("Access is denied", "SecurityError");
};

try {
	getAnonymousId();
} finally {
	Storage.prototype.getItem = originalGetItem;
}

3. Observe that getAnonymousId() throws SecurityError.

The same behavior occurs when getSessionId() encounters an inaccessible sessionStorage. The exception also propagates from getTrackingIds() and getTrackingParams().

Expected behavior

Storage access failures should be treated as missing tracking IDs:

getAnonymousId(); // null
getSessionId(); // null
getTrackingIds(); // { anonId: null, sessionId: null }
getTrackingParams(); // ""

If only one storage mechanism is unavailable, getTrackingIds() and getTrackingParams() should preserve the ID available from the other mechanism.

Explicit URLSearchParams values should continue to take priority without accessing the corresponding storage mechanism.

Screenshots

Not applicable. The failure is a thrown DOMException.

Environment (please complete the following information):

• OS: windows 11
• Browser: firefox
• Version: 154.0
• SDK version: @databuddy/sdk 2.6.0

Additional context

The affected code is in packages/sdk/src/core/tracker.ts.

Existing tests cover empty storage, populated storage, and URL-parameter precedence, but do not cover storage reads throwing.

A fix could follow the existing getProfileId() pattern by catching errors around each individual storage read and returning null.

AI usage disclosure

This issue report was drafted with OpenAI Codex. Codex inspected the affected SDK implementation, its call sites, existing tests, repository history, contribution guidelines, and AI usage policy. I personally reviewed and edited the report and reproduced the behavior before submission.

[aetosdios27]

I’ve started working on a PR for this.

After tracing the affected helpers and their call sites, the root cause is the unguarded storage access inside getAnonymousId() and getSessionId(). If either
localStorage or sessionStorage throws, the exception escapes the helper and propagates through getTrackingIds() and getTrackingParams().

This is particularly problematic for callers that treat tracking IDs as optional metadata. For example, the contact form calls getTrackingIds() before entering its
request try/catch, so restricted storage can prevent the actual submission instead of simply omitting the tracking IDs.

My approach for the PR is:

1. Check for a non-empty ID in the supplied URLSearchParams first and return it immediately. This preserves the existing URL-parameter precedence and ensures the
   corresponding storage mechanism is not accessed unnecessarily.
2. Wrap each storage read independently:
   • getAnonymousId() will catch failures from localStorage and return null.
   • getSessionId() will catch failures from sessionStorage and return null.
3. Keep the handling in the two leaf helpers instead of catching errors only in getTrackingIds() or getTrackingParams(). This also makes direct calls safe and allows
   one available ID to be preserved when only the other storage mechanism fails.
4. Preserve the current public API and existing behavior for SSR, empty storage, populated storage, and URL-provided IDs.

I’ll also add regression coverage for:

• getAnonymousId() when localStorage access throws;
• getSessionId() when sessionStorage access throws;
• both storage mechanisms being unavailable;
• localStorage failing while the session ID remains available;
• sessionStorage failing while the anonymous ID remains available;
• getTrackingParams() returning empty or partial output as appropriate;
• URL-provided IDs taking priority without touching the corresponding storage.

The fix will remain scoped to the SDK helpers and should not require any consumer-side changes.

[r69shabh]

Opened a PR for this: #641

Reproduced the issue, traced the callsites, and spotted that getProfileId() already handles this correctly in the same file. Applied the same try/catch pattern to getAnonymousId and getSessionId. Also made the URL-param check an explicit guard so storage isn't touched when a param is already present.

Added 8 Playwright tests covering all the scenarios from the issue. All tests pass.