[keelerm84]

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.

---

Note

Overview
Breaking change: LaunchDarkly::Interfaces::FeatureStore now requires monitoring_enabled?, available?, and stop with updated interface docs (no more optional/respond_to? probing).

The SDK stops inferring monitoring support from whether available? exists. Client wrappers (FeatureStoreClientWrapper, FeatureStoreClientWrapperV2) read @store.monitoring_enabled? directly, expose available? as a delegate, and drop the old store_supports_monitoring? / does_store_support_monitoring? helpers. StatusProviderV2 likewise trusts monitoring_enabled? on the store when present.

Built-in and integration paths are aligned: InMemoryFeatureStore adds available? → true; CachingStoreWrapper always reports monitoring enabled and forwards available? / stop to FeatureStoreCore (which now documents those methods). FDv2 Store#close always calls persistent_store.stop without a respond_to?(:stop) guard.

Specs and test doubles implement the new methods; a legacy test that assumed monitoring was off when available? was missing was removed.

^{Reviewed by Cursor Bugbot for commit 1b65ab6. Bugbot is set up for automated code reviews on this repo. Configure here.}