fix(statsig): improve plugin binding error handling during client ini…

[eldadfux]

…tialization

• Updated startStatsig function to check if Storage.isReady is a function before calling it.
• Moved plugin binding logic into a try/catch block to handle potential errors gracefully.
• Ensured that client registration for logEvent occurs immediately after core initialization to prevent logging failures.

Made-with: Cursor

What does this PR do?

(Provide a description of what this PR does.)

Test Plan

(Write your test plan here. If you changed any code, please provide us with clear instructions on how you verified your changes work.)

Related PRs and Issues

(If this PR is related to any other PR or resolves any issue or related to any issue link all related PR and issues here.)

Have you read the Contributing Guidelines on issues?

(Write your answer here.)

[greptile-apps]

Greptile Summary

This PR improves resilience of the Statsig browser client initialization in two ways: it adds a typeof guard before calling Storage.isReady() to avoid a potential TypeError if the SDK changes its interface, and it moves client assignment before the plugin-binding block so logEvent calls are not silently dropped when Session Replay or Auto Capture plugins throw (e.g., due to CSP or privacy extensions). The logic is sound and well-commented.

Confidence Score: 4/5

Safe to merge; changes are defensive improvements with no breaking logic.

Only a P2 style suggestion was found (adding a warn log for the silent storage-wait skip). Both core fixes (typeof guard and client assignment ordering) are logically correct and well-scoped.

No files require special attention.

Important Files Changed

Filename	Overview
src/lib/statsig/client.ts	Guards Storage.isReady with a typeof check and moves client assignment before plugin bind try/catch so logEvent works even when plugins fail; logic is sound with one minor silent-skip concern.

Comments Outside Diff (1)

1. src/lib/statsig/client.ts, line 90-95 (link)

   Silent storage-wait skip may resurface StableID lag

   When Storage.isReady is not a function (e.g., future SDK refactor), the guard silently skips the entire wait block. The inline comment above (lines 87–89) explicitly warns that skipping this wait causes stableID to lag userID and can produce bootstrap/evaluation mismatches in the dashboard. A console.warn here would at least make the degraded path visible in production telemetry.

_{Reviews (1): Last reviewed commit: "fix(statsig): improve plugin binding err..." | Re-trigger Greptile}