René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"Review thread safety of client/API/Evaluation context","articleBody":"Review the thread safety of the SDK to make sure there's no potential concurrency issues, particularly around state maintained in the global API object, clients, and evaluation context objects.\n\nSee [here](https://github.com/open-feature/java-sdk/issues/64) for a similar discussion in the Java SDK and others.\n\n## Background\n\nPython's GIL is sometimes mistaken for making threading a non-issue (like Node's single-threaded model), but they're not the same. The GIL only makes individual bytecode operations atomic; compound operations like check-then-act or read-modify-write are not safe. Providers commonly run background threads for connection management and emit events from them, so these races aren't just theoretical.\n\n## Audit\n\nHere's what we found. The only locks in the SDK today are in `_event_support.py` (and even those have some gaps). Everything else is unprotected.\n\n- **`ProviderRegistry` singleton** (`provider/_registry.py`) - this is the big one. No locks at all. `set_provider()` and `set_default_provider()` have check-then-act patterns with side effects (initialize/shutdown), so concurrent calls can double-shutdown, lose providers, or initialize providers that never get registered. `clear_providers()` has a window where shut-down providers are still returned to callers.\n- **Global `_hooks` list** (`hook/__init__.py`) - `add_hooks` does `_hooks = _hooks + hooks` which is a read-concat-rebind; two concurrent calls can lose one set of hooks\n- **`api.clear_providers()`** (`api.py`) - calls `provider_registry.clear_providers()` then `_event_support.clear()` as two separate steps; event handlers still exist but providers are gone in between\n- **`_event_support.py`** - has RLock (good), but immediate handler execution in `add_*_handler` runs outside the lock, and `clear()` acquires two separate locks non-atomically\n- **Global `_evaluation_context`** (`evaluation_context/__init__.py`) - no lock; TOCTOU across the evaluation pipeline (context can change between read and use)\n- **Global transaction context propagator** (`transaction_context/__init__.py`) - no lock; read-then-call-method races with propagator swap\n- **Client instance state** (`client.py`) - `self.hooks` has the same lost-update pattern as global hooks; `_assert_provider_status` reads `self.provider` again instead of using the reference captured earlier in the evaluation flow, so the status check can be for a different provider than the one actually used\n- **`AbstractProvider._on_emit`** (`provider/__init__.py`) - `emit()` does `if hasattr(self, \"_on_emit\"): self._on_emit(...)` which is a TOCTOU; `detach()` during shutdown can delete `_on_emit` while a background thread is between the check and the call\n\n## Definition of done\n\n- [ ] issues created for thread safety of global API, client, and evaluation context","author":{"url":"https://github.com/toddbaert","@type":"Person","name":"toddbaert"},"datePublished":"2023-04-18T13:33:27.000Z","interactionStatistic":{"@type":"InteractionCounter","interactionType":"https://schema.org/CommentAction","userInteractionCount":5},"url":"https://github.com/96/python-sdk/issues/96"}