fix: thread safety issues

[leakonvalinka]

This PR

• aims to improve the thread-safety of the python-sdk
• some of these changes still need to be discussed -> see comments (mentioning potential issues and options)

Related Issues

#96

Notes

• i'm not a python expert, please let me know if i got anything wrong :)

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 98.36%. Comparing base (79bb01b) to head (a172da9).

Additional details and impacted files

@@ Coverage Diff @@## main #614 +/- ##
==========================================
+ Coverage 98.34% 98.36% +0.02% 
==========================================
Files 45 45 Lines 2483 2514 +31 ==========================================
+ Hits 2442 2473 +31 
Misses 41 41 

Flag	Coverage Δ
unittests	98.36% <100.00%> (+0.02%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[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: 6a2b4de4-4a36-45df-9e10-322586ddd9c3

📥 Commits

Reviewing files that changed from the base of the PR and between 027a326 and a172da9.

📒 Files selected for processing (4)

• openfeature/client.py
• openfeature/hook/__init__.py
• openfeature/transaction_context/__init__.py
• spec

💤 Files with no reviewable changes (2)

• openfeature/hook/init.py
• openfeature/client.py

---

📝 Walkthrough

Walkthrough

This PR adds thread-safety locks around hook list mutations and the transaction context propagator, simplifies the provider emit callback dispatch, fixes a TOCTOU bug where _assert_provider_status used stale state instead of the resolved provider, updates related tests, and bumps the spec submodule commit.

Changes

Shared-state hardening

Layer / File(s)	Summary
Hook list locking openfeature/hook/__init__.py, openfeature/client.py	Global _hooks list and client hooks list mutations (add_hooks, clear_hooks) now occur under RLock-protected sections instead of unsynchronized reassignment.
Transaction context propagator locking openfeature/transaction_context/__init__.py	A module-level _propagator_lock guards assignment of the global propagator in set_transaction_context_propagator; set_transaction_context briefly locks to copy the reference before invoking it outside the lock.
Provider emit dispatch and provider-status TOCTOU fix openfeature/provider/__init__.py, openfeature/client.py, tests/test_client.py	emit uses getattr(self, "_on_emit", None) instead of hasattr; _assert_provider_status now takes an explicit provider argument and queries provider_registry.get_provider_status(provider) directly, with call sites updated accordingly; tests updated to mock provider_registry and a new regression test validates correct provider-specific status resolution.

Estimated code review effort: 3 (Moderate) | ~25 minutes

Related PRs: None identified.

Suggested labels: bug, enhancement, tests

Suggested reviewers: None identified.

🐇 A poem from the CodeRabbit

A rabbit locks the burrow tight,
so hooks don't tangle in the night,
the provider's status, checked just right,
no stale ghost to give a fright,
threads now hop in single file delight! 🔒🐰

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 8.82% 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 clearly matches the main change set, which focuses on fixing thread-safety issues in the Python SDK.
Description check	✅ Passed	The description is directly related to the PR and states that it aims to improve thread-safety in the python-sdk.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

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

[coderabbitai]

Actionable comments posted: 1

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (1)

openfeature/provider/_registry.py (1)

99-105: 🩺 Stability & Availability | 🔴 Critical | ⚡ Quick win

Avoid clearing event handlers while holding the registry lock.

clear_event_handlers() acquires _client_lock; concurrently, handler dispatch holds _client_lock while resolving client.provider, which now acquires ProviderRegistry._lock. This creates a registry-lock → client-lock path here and a client-lock → registry-lock path during dispatch, so clear_providers() can deadlock with provider event dispatch.

🔒 Proposed fix

 def clear_providers(self) -> None:
self.shutdown()
with self._lock:
self._providers.clear()
self._default_provider = NoOpProvider()
self._provider_status = {
self._default_provider: ProviderStatus.READY,
}
- clear_event_handlers()++ clear_event_handlers()

🤖 Prompt for 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.
In `@openfeature/provider/_registry.py` around lines 99 - 105, clear_providers()
is calling clear_event_handlers() while still holding ProviderRegistry._lock,
which creates a lock-order cycle with event dispatch. Move the
clear_event_handlers() call out of the locked section in
ProviderRegistry.clear_providers(), keeping only provider state updates under
the lock and then clearing handlers after the lock is released. Use the
ProviderRegistry._lock, clear_providers(), and clear_event_handlers() symbols to
update the flow so the registry lock is never held when acquiring the
client/event-handler lock.

🤖 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/transaction_context/__init__.py`:
- Around line 26-50: The transaction-context helpers can self-deadlock because
_propagator_lock is a non-reentrant Lock while get_transaction_context and
set_transaction_context invoke user-provided TransactionContextPropagator
methods under that lock. Update the locking strategy in
openfeature/transaction_context/__init__.py so re-entrant calls from custom
propagators do not block the same thread, for example by switching
_propagator_lock to an RLock and keeping the existing serialization around
set_transaction_context_propagator, get_transaction_context, and
set_transaction_context.
---
Outside diff comments:
In `@openfeature/provider/_registry.py`:
- Around line 99-105: clear_providers() is calling clear_event_handlers() while
still holding ProviderRegistry._lock, which creates a lock-order cycle with
event dispatch. Move the clear_event_handlers() call out of the locked section
in ProviderRegistry.clear_providers(), keeping only provider state updates under
the lock and then clearing handlers after the lock is released. Use the
ProviderRegistry._lock, clear_providers(), and clear_event_handlers() symbols to
update the flow so the registry lock is never held when acquiring the
client/event-handler lock.

🪄 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: 8e01e6e3-2b84-4dab-a926-10ec95fae6b5

📥 Commits

Reviewing files that changed from the base of the PR and between 79bb01b and 7f14e05.

📒 Files selected for processing (8)

• openfeature/_event_support.py
• openfeature/api.py
• openfeature/client.py
• openfeature/hook/__init__.py
• openfeature/provider/__init__.py
• openfeature/provider/_registry.py
• openfeature/transaction_context/__init__.py
• tests/test_client.py

💤 Files with no reviewable changes (1)

• openfeature/api.py

[aepfli]

I am curious, can we add a tool to detect this like vmlens in java? In the sense of automated testing?

[gruebel]

thanks 🍻 overall it looks pretty good and adds more thread safety especially when using free-threaded CPython

[leakonvalinka]

@aepfli I don't think so, unfortunetly. I did try to write a few tests and also have Claude write some with threading.Barrier & run them a few thousand times with pytest repeat, but they didn't reliably catch any issues even before the fixes were implemented.

[gruebel]

@leakonvalinka let me know, if you need some help to finish up the last parts. I don't want you to be stuck with this PR for much longer, sorry!

[leakonvalinka]

@gruebel Thank you! I implemented the remaining feedback, if you notice something else feel free to just change it if you want.

[gruebel]

thanks for contribution 🍻 i'll wait till end of week, if there are no other objections