Context

PostHog identifyUser was previously only called during login, signup, and OAuth callback routes. Users accessing Infisical via CLI, SDK, or API would not get their PostHog person properties enriched if those one-time calls were missed or if the person record was created with a different distinctId.

This PR adds identifyUser calls in the inject-identity.ts authentication hook for JWT and MCP_JWT auth modes. This ensures that every authenticated request — regardless of client (CLI, SDK, API, UI) — enriches the PostHog person with basic properties (email, username, userId).

To avoid excessive PostHog API calls, a Redis-backed dedup cache (10-minute TTL) is used via an atomic SET NX EX operation (setItemWithExpiryNX). If a user was already identified within the last 10 minutes, the call is skipped. All existing login/signup/OAuth identifyUser call sites are updated to use skipDedup: true so they always fire (they carry richer properties like firstName, lastName, superAdmin).

Note: This is the first of two PRs. A separate PR in the CLI repo (Infisical/cli#146) addresses the anonymous distinctId issue where the CLI generates random IDs instead of using the user's email/username.

Updates since last revision

Addressed all code review feedback across four rounds of Greptile review and Devin Review:

1. TOCTOU race fix: Replaced non-atomic getItem + setItemWithExpiry with a single atomic setItemWithExpiryNX (Redis SET key value EX ttl NX). Only the first caller within the TTL window proceeds; all others get null back and skip the identify call.
2. Redis outage blast radius: Added an in-memory Set<string> fallback in the catch block. If Redis is unreachable, the in-memory set absorbs the burst (entries auto-expire via setTimeout matching the cache TTL) instead of flooding PostHog with identify calls on every request.
3. Code duplication: Extracted a fireIdentifyForUser(user) helper in inject-identity.ts, called in both JWT and MCP_JWT cases.
4. Keystore additions: Added setItemWithExpiryNX to TKeyStoreFactory type, implementation, mock (e2e-test/mocks/keystore.ts), and in-memory store (keystore/memory.ts).
5. Hot-path optimization: Hoisted fireIdentifyForUser to plugin scope (outside onRequest hook, inside injectIdentity) so the function is created once per plugin registration instead of per-request.
6. Defensive try/catch on postHog.identify(): Wrapped the postHog.identify() call in a try/catch to prevent unhandled promise rejections from propagating when call sites use void.
7. Error log context: Included distinctId in error log messages for both the dedup cache and postHog.identify() failures, improving production debuggability.
8. Graceful shutdown fix: Added .unref() to the fallback setTimeout in identifyUser, consistent with the existing identifyIdentity pattern. Without .unref(), active timers during Redis outages would keep the Node.js event loop alive and prevent graceful shutdown for up to 600 seconds.

Steps to verify the change

1. Deploy to a Cloud instance
2. Log in via CLI and make an authenticated API request (e.g. infisical secrets)
3. Check PostHog — the person record for that user should have email, username, and userId properties set
4. Make additional requests within 10 minutes — verify no duplicate $identify events are sent (dedup cache working)
5. Verify login/signup/OAuth flows still fire identifyUser on every occurrence (skipDedup)

Important review notes

• identifyUser is now async but all call sites use void (fire-and-forget) — this is intentional for telemetry
• The auth hook calls pass only email, username, userId — the richer property set (firstName, lastName, superAdmin, etc.) is still set by login/signup routes via skipDedup: true
• The in-memory fallback Set is per-process (not shared across instances). This is intentional — it's a last-resort rate limiter, not a primary dedup mechanism
• setTimeout entries accumulate one per distinct user during a Redis outage; review whether this is acceptable under expected concurrent user counts
• distinctId is derived from user.username ?? user.email. In the unlikely edge case where these values collide across accounts, dedup could suppress identification for up to 10 minutes (telemetry-accuracy impact only, not a security concern)

Human review checklist

• Verify setItemWithExpiryNX return type ("OK" | null) is handled correctly — null means key already existed (skip identify)
• Check that setTimeout accumulation in inMemoryIdentifyDedup won't cause issues during extended Redis outages with many distinct users
• Confirm identifyUser becoming async doesn't break anything (all call sites use void so should be safe)
• Verify the fireIdentifyForUser helper correctly extracts the shared logic without altering behavior
• Confirm the try/catch around postHog.identify() is appropriate and won't mask legitimate errors
• Review that including distinctId (email/username) in error logs doesn't introduce PII logging concerns in your environment
• Verify that timer.unref() is called on both identifyUser and identifyIdentity fallback timers for graceful shutdown consistency

Type

• Fix
• Feature
• Improvement
• Breaking
• Docs
• Chore

Checklist

• Title follows the conventional commit format
• Tested locally
• Updated docs (if needed)
• Read the contributing guide

Link to Devin Session: https://app.devin.ai/sessions/6cf49960d59a4f7b974a7fe4861d6206
Requested by: @0xArshdeep