fix: isolate provider event handler dispatch

[Lucas-FManager]

Problem

Provider event handlers currently execute synchronously while the handler registry lock is held. That means a handler exception can stop later handlers, and a slow handler can block the provider/client path that emitted the event.

Approach

• Snapshot global/client handlers under the lock, then release the lock before dispatch.
• Dispatch handlers through a shared ThreadPoolExecutor.
• Wrap each handler invocation so one failing handler is logged and does not prevent the next handler from running.
• Avoid the nested client-handler lock pattern in provider dispatch by snapshotting matching clients first.
• Update event tests to wait for async handler dispatch and add coverage for error isolation and non-blocking emission.

Security

This avoids running arbitrary user event-handler code while internal handler registries are locked. It also keeps handler exceptions contained to the callback boundary instead of propagating into SDK/provider control flow.

Verification

• uv run pytest tests -q -> 158 passed
• uvx ruff check openfeature/_event_support.py tests/test_client.py tests/test_api.py -> passed
• uvx ruff format --check openfeature/_event_support.py tests/test_client.py tests/test_api.py -> passed
• git diff --check -> passed

Fixes#596

[gemini-code-assist]

Code Review

This pull request introduces asynchronous event handling using a ThreadPoolExecutor to execute OpenFeature event handlers, ensuring they do not block the emitter or other handlers. It also refactors locking mechanisms to release locks before handler execution and wraps handler execution in try-except blocks to prevent a single failing handler from halting subsequent ones. The review feedback recommends avoiding unnecessary mutation and potential memory leaks in defaultdict lookups by checking if keys exist before accessing them in both client and global handler registries.

[Lucas-FManager]

Updated in the latest push: run_client_handlers() now uses _client_handlers.get(client) and then handlers_by_event.get(event, ()), and run_global_handlers() uses _global_handlers.get(event, ()). That avoids mutating the defaultdict during read-only dispatch while preserving the async/error-isolated behavior.

Re-verified after the change:

• uv run pytest tests -q -> 158 passed
• uvx ruff check openfeature/_event_support.py tests/test_client.py tests/test_api.py -> passed
• uvx ruff format --check openfeature/_event_support.py tests/test_client.py tests/test_api.py -> passed
• git diff --check -> passed

[gruebel]

overall looks good and addresses the mentioned issues. added just a few comments, thanks 🍻

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 98.34%. Comparing base (cbacef0) to head (a049b00).

Additional details and impacted files

@@ Coverage Diff @@## main #599 +/- ##
==========================================
+ Coverage 98.28% 98.34% +0.06% 
==========================================
Files 45 45 Lines 2386 2477 +91 ==========================================
+ Hits 2345 2436 +91 
Misses 41 41 

Flag	Coverage Δ
unittests	98.34% <100.00%> (+0.06%)	⬆️

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

☔ View full report in Codecov by Sentry.
📢 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.

[Lucas-FManager]

Small follow-up after the Codecov report: I added a focused regression test for the read-only client-dispatch no-op path, so _event_support.py is locally covered at 100%.

Verification after the new commit:

• uv run pytest tests/test_client.py tests/test_api.py -q -> 74 passed
• uv run coverage run -m pytest tests/test_client.py tests/test_api.py -q; uv run coverage report -m openfeature/_event_support.py -> _event_support.py 100%
• uvx prek run --all-files --show-diff-on-failure -> passed

The main build workflow is still waiting for maintainer approval for the fork run, so there is no new CI failure on the latest head yet.

[toddbaert]

I made some small test improvements, and also shut down the executor on exit.