feat: implement waitForInitialization for browser sdk 4.x
#1028
Conversation
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
Contributor
|
@launchdarkly/browser size report |
Contributor
|
@launchdarkly/js-sdk-common size report |
Contributor
|
@launchdarkly/js-client-sdk size report |
Contributor
|
@launchdarkly/js-client-sdk-common size report |
kinyoklion
reviewed
Dec 4, 2025
kinyoklion
reviewed
Dec 4, 2025
joker23
force-pushed
the
skz/sdk-1360/browser-4.x-waitforinit
branch
from
d324724 to
acf1ac7
Compare
![cursor[bot]](https://avatars.githubusercontent.com/in/1210556?s=60&v=4){kind=small}
3 tasks
unit tests broke because we introduced retries on initial polls which timed out of initial wait tests (since those tests were using fake timers). This change would simply advance the fake timer so all retries would have been triggered.
This commit will also fix this issue
kinyoklion
approved these changes
Dec 12, 2025
| } else if (res.status === 'error') { | ||
| this._initializeResult = { status: 'failed', error: res.error }; | ||
| this._initResolve?.(this._initializeResult); | ||
| } |
There was a problem hiding this comment.
Bug: Stale initialization state persists across multiple identify calls
The _initializeResult state is set when an identify call completes but is never reset when a new identify starts. If a user calls identify successfully, then calls identify again for a different context, and then calls waitForInitialization, the method will immediately return the stale result from the first identify rather than waiting for the in-progress second identify to complete. The initialization state (_initializeResult, _initializedPromise, and _initResolve) needs to be reset at the start of each identifyResult call.
Additional Locations (1)
joker23
force-pushed
the
skz/sdk-1360/browser-4.x-waitforinit
branch
from
71a20ce to
262c6fe
Compare
joker23
added a commit
that referenced
this pull request
Dec 17, 2025
**Requirements**
- [x] I have added test coverage for new or changed functionality
- [x] I have followed the repository's [pull request submission
guidelines](../blob/main/CONTRIBUTING.md#submitting-pull-requests)
- [x] I have validated my changes against all supported platform
versions
sdk-1653
sdk-1565
**Describe the solution you've provided**
- Added `LDDebugOverride` interface to manage flag value overrides
during development.
- Introduced `safeRegisterDebugOverridePlugins` function to register
plugins with debug capabilities.
- Updated `FlagManager` to support debug overrides, including methods to
set, remove, and clear overrides.
- Enhanced `LDClientImpl` to utilize debug overrides during client
initialization.
- Refactored `LDPlugin` interface to include optional `registerDebug`
method for plugins.
This PR will enable `@launchdarkly/toolbar` to use 4.x
**Additional context**
- ~This PR is based off of
#1028 (will need to do some
rebase magic later)~
- There are a few places that I've marked `REVIEWER` that I would like
some additional discussions before merging
- In this change we are assuming that the plugin support (eg registering
plugins) is still the responsibility of individual SDK implementations.
<!-- CURSOR_SUMMARY -->
---
> [!NOTE]
> Introduces a debug flag override interface, wires plugin registration
for overrides, and updates flag management and clients to support and
emit override-driven changes.
>
> - **Flag management**:
> - Add `LDDebugOverride` interface and implement in
`DefaultFlagManager` (`setOverride`, `removeOverride`,
`clearAllOverrides`, `getAllOverrides`).
> - `get`/`getAll` now merge in-memory overrides with stored flags;
override values take precedence.
> - Emit change callbacks with type `"override"` via
`FlagUpdater.handleFlagChanges`.
> - **Updater**:
> - Extend `FlagChangeType` with `"override"`; add `handleFlagChanges`
helper; refactor `init`/`upsert` to use it.
> - **Client integration**:
> - `LDClientImpl`: expose `getDebugOverrides()` from `FlagManager` and
continue inspection updates on changes.
> - Browser client: during `registerPlugins`, call
`safeRegisterDebugOverridePlugins` to pass overrides to plugins.
> - **Plugin API & utilities**:
> - Add `LDPluginBase.registerDebug(debugOverride)` optional method.
> - New `safeRegisterDebugOverridePlugins` utility to safely register
debug override plugins.
> - **Exports**:
> - Re-export `LDPluginBase`, `LDDebugOverride`, and
`safeRegisterDebugOverridePlugins` in public entrypoints.
> - **Tests**:
> - Add comprehensive `FlagManager` override tests covering precedence,
callbacks, clearing, and merging.
>
> <sup>Written by [Cursor
Bugbot](https://cursor.com/dashboard?tab=bugbot) for commit
2bf10a3. This will update automatically
on new commits. Configure
[here](https://cursor.com/dashboard?tab=bugbot).</sup>
<!-- /CURSOR_SUMMARY -->
---------
Co-authored-by: Ryan Lamb <[email protected]>
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.
Requirements
Related issues
waitForInitializeto browser 4.xDescribe the solution you've provided
Added
waitForInitializationfunction to browser 4.x implementation.Additional context
f({timeout: 5})instead off(5)rejectconditions... I can add those back in case we get an error status returned? At that point we might want to just wait for the timeout to throw.initializedevent that a successful identify will emit, I figured that would be a way for developers to know if LDClient initialized even if the initialization goes past timeout.Note
Introduces waitForInitialization to the browser client with a configurable timeout and explicit success/failed/timeout results, and emits an initialized event on successful identify, with comprehensive tests.
waitForInitialization(options)toLDClientwith default 5s timeout, returningcomplete | failed | timeoutresults; supports multiple calls and immediate return if already resolved.cancelableTimedPromiseand internal_promiseWithTimeoutto race initialization vs timeout.identifyResultnow resolves the initialization promise ascompleteorfailedand starts goal tracking."initialized"event to emitter and emit it on successful identify.LDWaitForInitializationOptions/Resulttypes and expose method in public client; wire throughmakeClient.waitForInitializationfrom the compatLDClientinterface.waitForInitializationcovering success, timeout, and failure (before/after calling).Written by Cursor Bugbot for commit 262c6fe. This will update automatically on new commits. Configure here.