Describe the bug
The SDK helper getSessionId() (packages/sdk/src/core/tracker.ts) reads did_session from sessionStorage and returns it as-is, without checking the did_session_timestamp that the tracker writes alongside it.
The tracker itself rotates sessions after 30 minutes of inactivity — getOrCreateSessionId() compares did_session_timestamp against that window, discards the stale pair, and generates a new id. But the SDK helper ignores the timestamp, so between expiry and the tracker's next visit it returns a session id that is no longer the current one.
getTrackingIds() and getTrackingParams() inherit the problem since they delegate to getSessionId().
To Reproduce
- Load a page with the tracker and
@databuddy/sdk.
- After the tracker initializes, backdate the timestamp past the expiry window:
sessionStorage.setItem("did_session_timestamp", String(Date.now() - 31 * 60 * 1000));
getSessionId(); // returns the stale id
- The tracker treats this session as expired and rotates it on the next init, but
getSessionId() keeps returning the old id. Same result if did_session_timestamp is missing entirely.
Expected behavior
getSessionId() should apply the same rule as the tracker: null when the timestamp is missing or older than 30 minutes. Fresh sessions still return the stored id, and URL params keep priority.
Screenshots
Not applicable. The failure is a logically stale return value.
Environment (please complete the following information):
- SDK:
@databuddy/sdk at current staging
- Browser-agnostic; reproduced through the SDK's Playwright suite
Additional context
The expiry logic lives in the tracker: packages/tracker/src/core/tracker.ts — getOrCreateSessionId() uses sessionAge < 30 * 60 * 1000. The SDK helper currently has no awareness of it.
Affected code: getSessionId() in packages/sdk/src/core/tracker.ts.
Existing tests cover empty storage, populated storage, and URL-parameter precedence, but not the expiry timestamp.
AI usage disclosure
This report was drafted with AI assistance (Claude via Qoder) for research and writing. I read the tracker and SDK sources, reproduced the mismatch in the SDK's test setup, and reviewed/edited the report before submitting.
Describe the bug
The SDK helper
getSessionId()(packages/sdk/src/core/tracker.ts) readsdid_sessionfrom sessionStorage and returns it as-is, without checking thedid_session_timestampthat the tracker writes alongside it.The tracker itself rotates sessions after 30 minutes of inactivity —
getOrCreateSessionId()comparesdid_session_timestampagainst that window, discards the stale pair, and generates a new id. But the SDK helper ignores the timestamp, so between expiry and the tracker's next visit it returns a session id that is no longer the current one.getTrackingIds()andgetTrackingParams()inherit the problem since they delegate togetSessionId().To Reproduce
@databuddy/sdk.getSessionId()keeps returning the old id. Same result ifdid_session_timestampis missing entirely.Expected behavior
getSessionId()should apply the same rule as the tracker:nullwhen the timestamp is missing or older than 30 minutes. Fresh sessions still return the stored id, and URL params keep priority.Screenshots
Not applicable. The failure is a logically stale return value.
Environment (please complete the following information):
@databuddy/sdkat currentstagingAdditional context
The expiry logic lives in the tracker:
packages/tracker/src/core/tracker.ts—getOrCreateSessionId()usessessionAge < 30 * 60 * 1000. The SDK helper currently has no awareness of it.Affected code:
getSessionId()inpackages/sdk/src/core/tracker.ts.Existing tests cover empty storage, populated storage, and URL-parameter precedence, but not the expiry timestamp.
AI usage disclosure
This report was drafted with AI assistance (Claude via Qoder) for research and writing. I read the tracker and SDK sources, reproduced the mismatch in the SDK's test setup, and reviewed/edited the report before submitting.