fix: race condition between status check and provider lookup

[NeaguGeorgiana23]

This PR

Resolves the race condition between the provider status check and the provider lookup during flag evaluation.

To ensure thread-safety and consistent evaluation state under concurrent provider swaps, this PR refactors the evaluation flow to retrieve the provider and its status atomically:

Updates ClientAPI::EvaluateFlag to retrieve the FeatureProviderStatusManager atomically from the repository in a single locked operation.
Uses this single manager instance as the sole source of truth for both the status check and the provider retrieval, ensuring they are always consistent.
Guarantees that even if a concurrent provider swap occurs (via SetProvider), the ongoing evaluation safely completes using the consistent state of the provider that was active when the evaluation started.

Related Issues

Fixes #69

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro Plus

Run ID: f0c436e2-e38d-40a3-bd19-55292bcc503b

📥 Commits

Reviewing files that changed from the base of the PR and between 2be23ba and 8d1e0da.

📒 Files selected for processing (1)

• openfeature/client_api.h

🚧 Files skipped from review as they are similar to previous changes (1)

• openfeature/client_api.h

---

📝 Walkthrough

Walkthrough

ClientAPI::EvaluateFlag in openfeature/client_api.h now gets provider status through provider_repository_.GetFeatureProviderStatusManager(domain_) and returns an error when no manager exists. It also uses the status manager to retrieve the provider instance.

Changes

Provider Status Lookup Fix

Layer / File(s)	Summary
Status manager lookup and provider access openfeature/client_api.h	EvaluateFlag now reads status from manager->GetStatus(), returns ResolutionDetailsType with Reason::kError and ErrorCode::kGeneral when no status manager is found, and gets the provider from manager->GetProvider().

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~5 minutes

Possibly related PRs

• open-feature/cpp-sdk#96: Modifies the same ClientAPI::EvaluateFlag provider-state handling path and related status-based evaluation flow.

Suggested reviewers

• oxddr
• toddbaert

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 33.33% which is insufficient. The required threshold is 80.00%.	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title accurately summarizes the main change: fixing the race between provider status checks and provider lookup.
Description check	✅ Passed	The description matches the implemented change and the stated race-condition fix.
Linked Issues check	✅ Passed	The PR addresses issue #69's unchecked race condition by using one status manager for both status and provider lookup.
Out of Scope Changes check	✅ Passed	The changes appear scoped to the race-condition fix in ClientAPI::EvaluateFlag with no unrelated additions.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

📝 Generate docstrings

• Create stacked PR
• Commit on current branch

---

_{Comment @coderabbitai help to get the list of available commands.}

[coderabbitai]

Actionable comments posted: 1

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@openfeature/client_api.h`:
- Around line 116-125: The code obtains a FeatureProviderStatusManager instance
from the repository to check status, but then re-queries the repository
separately to get the provider, which creates a race condition where a
concurrent SetProvider call could change the provider between these two
operations, causing status and the evaluated provider to diverge. Instead of
calling the repository twice, reuse the same FeatureProviderStatusManager
instance obtained from provider_repository_.GetFeatureProviderStatusManager to
retrieve both the status and the provider, ensuring they remain consistent and
come from the same logical snapshot.

🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro Plus

Run ID: a1ac1b09-ef8b-415d-9743-577b73b80634

📥 Commits

Reviewing files that changed from the base of the PR and between 9c99e7b and 212e050.

📒 Files selected for processing (1)

• openfeature/client_api.h

[Copilot]

Pull request overview

This PR refactors ClientAPI::EvaluateFlag to eliminate a race where provider status could be checked against one provider while the evaluation call used another provider after a concurrent SetProvider swap. It does this by retrieving a single FeatureProviderStatusManager instance from the repository and using it as the consistent source for both status and provider lookup during evaluation.

Changes:

• Update ClientAPI::EvaluateFlag to fetch a FeatureProviderStatusManager once and use it for both GetStatus() and GetProvider().
• Add an explicit error-return path when no status manager can be obtained for the domain.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.