Repository navigation
fix(identify): send a userHash once even when the cached identity is unchanged - #200
Merged
Merged
Conversation
…unchanged (#227678) identifySession skipped any identify whose userId and data matched the cached session, also when it now carries a userHash. A contact identified without a hash before (an older app version, identity verification switched on later, a sign-up identified before it could get a hash) therefore never sent the hash, and the server never marked it as proved (session.signedUserId). In Gleap's own support project that kept long-signed-in dashboard users "unverified" for Kai. The SDK now remembers `<gleapId>:<userId>` once a hashed identify landed (memory + cache, cleared on logout) and sends a hashed identify when that record does not match the current session and user. The hash itself is never stored. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
TobiasDuelli
approved these changes
Nov 4, 2026
Merged
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Symptom
Customers who pass a
userHashtoGleap.identifystay unproved on the server when the browser already holds a session identified with the same userId and data without a hash. Seen in Gleap's own support widget: signed-in dashboard users identified before the dashboard started sending a hash stay unverified.Root cause
identifySessionreturns early whencheckIfSessionNeedsUpdatefinds the cached session already has this userId and the same name/email. TheuserHashis not part of that check, so the request that carries it is never sent and the server never writessession.signedUserId. Only a logout (clearIdentity) or a new browser sends it.Production data (Gleap's own support widget, contacts active since the server-side mark shipped): about 230 older contacts were proved through a logout or a new browser. About 330 others were not, although they used the dashboard after the change.
Fix
The session remembers
<gleapId>:<userId>once an identify with auserHashsucceeded (memory, plus the cache unless localStorage is disabled; cleared inclearSession). An identify with auserHashis sent when that record does not match the current session and user, so each browser sends the hash once and then skips again. Only the user id is stored, never the hash. Identifies without a hash behave as before.Verification
src/GleapSession.test.js("identify with a userHash on a session identified without one"): 3 of 4 fail on master (no request sent), all pass with the fix. They cover: sent once and skipped on the next page load, re-sent after a failed request, unchanged identify without a hash still skipped, record forgotten on logout.Follow-up after merge: release the SDK and bump
gleapin the dashboard so it ships there.🤖 Generated with Claude Code