Repository navigation
Conversation
The SDK no longer checks with respond_to? for the optional feature store methods. Custom stores must now implement them. A custom LaunchDarkly::Interfaces::FeatureStore must implement: - monitoring_enabled? -- return true only if the store publishes status updates when it becomes unavailable and when it recovers. In-memory stores return false. - available? -- return true if the underlying data store is reachable. The SDK polls this method after a store operation fails, while monitoring is enabled. Stores that cannot become unavailable return true. - stop -- release resources. The SDK calls it when the client closes. A custom FeatureStoreCore used with CachingStoreWrapper must implement available? and stop. CachingStoreWrapper now always reports monitoring_enabled? as true and delegates available? to the core. Before this change, a store without these methods silently lost status monitoring, and a core without available? turned monitoring off. The interface docs also disagreed on whether available? would stay. Making the methods required gives one clear contract and removes the probing. The lifecycle method stays named stop. All built-in stores, the big segment store, data sources and event processors already use stop, so renaming only the feature store to close would make the SDK less consistent.
…pplied FeatureStore#upsert and FeatureStore#delete must now return true when the store applies the write, and false when the store already has an item with the same or a higher version. FeatureStoreCore#upsert_internal, used with CachingStoreWrapper, must return the same boolean instead of the final item. Before this change, the SDK sent flag change events after every upsert or delete from the data source, even when the store rejected a stale write. A repeated or out-of-order update therefore produced change events for flags that did not change. The SDK now updates its dependency tracking and sends change events only when the store reports that it applied the write. When a core reports that it did not apply an upsert, CachingStoreWrapper reads the current item from the core and caches it. This matches the Go SDK's persistent store wrapper. Custom store implementers: - A FeatureStore that returns nil or another falsy value from upsert or delete stops flag change events for those writes. The default methods in LaunchDarkly::Interfaces::FeatureStore return nil, so implementations must return the result explicitly. - A FeatureStoreCore must return true or false from upsert_internal. The wrapper no longer accepts the final item as the return value.
This branch has not been deployed
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.
FeatureStore#upsert and FeatureStore#delete must now return true when the
store applies the write, and false when the store already has an item with
the same or a higher version. FeatureStoreCore#upsert_internal, used with
CachingStoreWrapper, must return the same boolean instead of the final item.
Before this change, the SDK sent flag change events after every upsert or
delete from the data source, even when the store rejected a stale write. A
repeated or out-of-order update therefore produced change events for flags
that did not change. The SDK now updates its dependency tracking and sends
change events only when the store reports that it applied the write.
When a core reports that it did not apply an upsert, CachingStoreWrapper
reads the current item from the core and caches it. This matches the Go
SDK's persistent store wrapper.
Custom store implementers:
delete stops flag change events for those writes. The default methods in
LaunchDarkly::Interfaces::FeatureStore return nil, so implementations
must return the result explicitly.
wrapper no longer accepts the final item as the return value.