Skip to content

Conversation

@typotter
Copy link
Contributor

@typotter typotter commented Dec 8, 2025

Summary

Clarifies the semantics of FlagsClientState.NotReady to support OpenFeature integration.

Changes

FlagsClientState.kt:

  • Enhanced NotReady documentation explaining when this state occurs
  • Documented mapping to OpenFeature's NOT_READY state
  • Clarified pre-initialization vs post-shutdown usage

NoOpFlagsClient.kt:

  • Changed state from Error(null) to NotReady
  • Rationale: No-op client is not in error state, it's simply not ready/unavailable

NoOpFlagsClientTest.kt:

  • Updated test expectations to match new NotReady state

Motivation

The OpenFeature spec defines NOT_READY as a valid pre-initialization and post-shutdown state,
not an error condition. These clarifications ensure FlagsClient state semantics align with
OpenFeature expectations.

Dependencies

This PR builds on PR #3042 (State management) and is required for PR #2998 (OpenFeature provider).

🤖 Generated with Claude Code

Updates FlagsClientState.NotReady documentation to clarify its usage:
- Used before first setEvaluationContext() call (pre-initialization)
- Used after client shutdown
- Maps to OpenFeature's NOT_READY state

Changes NoOpFlagsClient to return NotReady instead of Error(null) since
a no-op client is not in an error state - it's simply not ready/available.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude Sonnet 4.5 (1M context) <[email protected]>
@typotter typotter requested a review from a team as a code owner December 8, 2025 17:34
@typotter typotter closed this Dec 8, 2025
@typotter typotter deleted the typo/flags-not-ready-clarifications branch December 8, 2025 17:46
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants