fix: Synchronize provider state access on the state lock - #54
Merged
kinyoklion merged 1 commit intoAug 25, 2026
Merged
Conversation
Copy link
Copy Markdown
Member
Sorry, something went wrong.
Co-Authored-By: rlamb@launchdarkly.com <4955475+kinyoklion@users.noreply.github.com>
Copy link
Copy Markdown
Contributor
🤖 Devin AI EngineerI'll be helping with this pull request! Here's what you should know: ✅ I will automatically:
Note: I can only respond to comments from users who have write access to this repository. ⚙️ Control Options:
|
Sorry, something went wrong.
keelerm84
approved these changes
Aug 25, 2026
kinyoklion
pushed a commit
that referenced
this pull request
Aug 25, 2026
🤖 I have created a release *beep* *boop* --- ## [1.2.0](1.1.3...1.2.0) (2026-08-25) ### Features * Deprecate the provider getState method ([#55](#55)) ([1f71ef3](1f71ef3)) * Populate OpenFeature flag metadata from the evaluation reason ([#56](#56)) ([153eaa3](153eaa3)) ### Bug Fixes * Synchronize provider state access on the state lock ([#54](#54)) ([ebe9513](ebe9513)) --- This PR was generated with [Release Please](https://github.com/googleapis/release-please). See [documentation](https://github.com/googleapis/release-please#release-please). <!-- CURSOR_SUMMARY --> --- > [!NOTE] > **Overview** > **Release Please** bumps the library from **1.1.3** to **1.2.0** in `gradle.properties` and `.release-please-manifest.json`, and adds the **1.2.0** section to `CHANGELOG.md`. No runtime code changes in this diff. > > The published **1.2.0** release (already on `main`) includes: **deprecated** `Provider.getState()` with guidance to use `Client.getProviderState()`; **flag metadata** on evaluations derived from LaunchDarkly evaluation reason fields; and **thread-safe** provider state reads/writes via synchronization on the state lock. > > <sup>Reviewed by [Cursor Bugbot](https://cursor.com/bugbot) for commit a86744b. Bugbot is set up for automated code reviews on this repo. Configure [here](https://www.cursor.com/dashboard/bugbot).</sup> <!-- /CURSOR_SUMMARY --> Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
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.
getState() synchronized on the state field's value instead of the stateLock monitor, so reads were never mutually exclusive with writes.
@cursor review
Implementation detailsRoot cause
synchronized (state) locks on the ProviderState enum constant currently referenced by the field. A reader holding the monitor of ProviderState.NOT_READY does not exclude a writer holding stateLock, so state transitions had no happens-before relationship with reads. Because enum constants are JVM-wide singletons, it also meant contending on a monitor shared with any other code that happens to lock the same constant.
initialize also wrote state = ProviderState.READY and later read state without any lock, on a different thread than the data source status listener that mutates it.
Alternatives considered
Making the field volatile would fix visibility, but the VALID branch of handleDataSourceStatus needs a compare-and-set over the field, so the lock is still required; keeping a single lock is simpler than mixing both.
Testing
./gradlew test — all 44 tests pass. The existing LifeCycleTest cases already assert the state transitions this lock protects (NOT_READY → READY, and → ERROR on a failed data source); a test cannot deterministically observe the previous incorrect locking, so no new test is added.
No visual preview applies — this is a server-side provider change.
Link to Devin session: https://app.devin.ai/sessions/0c452d209ec54b068ba120b4c92b8f6c
Requested by: @kinyoklion
Note
Overview
Fixes incorrect locking around the OpenFeature provider lifecycle state so reads and writes use the same monitor.
getState() now synchronizes on stateLock instead of on the ProviderState enum value held in the field, which did not exclude concurrent updates from setState and could contend on JVM-wide enum monitors. initialize routes the early-ready path through setState(READY) and the readiness check through getState() instead of assigning or reading the state field without the lock.
Callers should see the same transitions, with correct visibility and mutual exclusion when the data source listener updates state on another thread.
Reviewed by Cursor Bugbot for commit dfc2c89. Bugbot is set up for automated code reviews on this repo. Configure here.