open-feature / open-feature/spec
Supply the bound domain to provider initialization across SDKs
Nobody has claimed this yet.
- Dominant language
- Python
- Stars
- 1.3k
- Forks
- 58
- Avg merge
- 2d 18h
- Merged PRs (30d)
- 2
Description
Context
The spec now supplies the bound domain to a provider's initialize function, and adds an opt-in domain-scoped provider declaration that the API enforces by binding such a provider to at most one domain. This lets stateful providers (e.g. an OFREP static-context provider with a persistent cache) scope their state to a single, unambiguous domain.
- Spec PR: https://github.com/open-feature/spec/pull/393
- Related protocol ADR: https://github.com/open-feature/protocol/pull/80 (OFREP cache key motivating this)
Relevant spec sections
Requirements summary
| Requirement | Level | Description |
|---|---|---|
| 1.1.2.2 | MUST | The provider mutator supplies the bound domain (if any) when invoking initialize |
| 2.4.1 | MAY | initialize accepts the global evaluation context and an optional bound domain |
| 2.4.3 | MAY | A provider may declare itself domain-scoped (maintains per-domain state that can't be shared) |
| 2.4.4 | MUST | A domain-scoped provider must accept the bound domain during initialization |
| 1.1.8 / 1.1.8.1 | MUST NOT | The provider mutator must not bind a domain-scoped provider instance to more than one domain, rejecting any attempt to bind an already-bound instance to an additional domain |
Section 1.8.4 prose was also updated: a provider instance can back multiple domains unless it declares itself domain-scoped.
Non-functional requirements
- Add the
domainparameter in a backwards-compatible way where the language allows it (optional/overloaded/default parameter). This is non-breaking in JS, Java, Python, .NET, Ruby, and Rust. - In languages where
initialize/Initis a required interface/protocol method (Go, Kotlin, Swift), introduce it via an optional secondary interface or batch it into the next major; thedomain-scopeddeclaration should likewise be opt-in. - PHP has no initialization hook today; adding one is out of scope here unless done separately.
- Associated testing and README/docs updates.
Implementation tracking
Child issues:
- JS: https://github.com/open-feature/js-sdk/issues/1434
- Java: https://github.com/open-feature/java-sdk/issues/1981
- Go: https://github.com/open-feature/go-sdk/issues/518
- Python: https://github.com/open-feature/python-sdk/issues/615
- .NET: https://github.com/open-feature/dotnet-sdk/issues/772
- Ruby: https://github.com/open-feature/ruby-sdk/issues/297
- Rust: https://github.com/open-feature/rust-sdk/issues/135
- Kotlin: https://github.com/open-feature/kotlin-sdk/issues/248
- Swift: https://github.com/open-feature/swift-sdk/issues/121
- Docs: https://github.com/open-feature/openfeature.dev/issues/1405
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with the relevant specification sections on flag evaluation and initialization, then review the requirements summary and the linked child issues for each SDK and the docs. Confirm which specification wording and compatibility expectations remain to be coordinated; the work is done when the applicable SDK and documentation child issues reflect the finalized requirements.
Written by the indexing model from the issue text.
Assessment
- Domain
- documentation
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 28/100