You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
fix(unleash): accept the arguments the client passes to track - #474
UnleashProvider.track declared (event_name, event_details), but OpenFeatureClient.track calls it with (name, context, details), so every client.track() raised TypeError. It now takes the SDK's signature and stays a no-op. The details are typed Any so it still type-checks against openfeature-sdk 0.8.
Checked with mypy and pytest under openfeature-sdk 0.8.4 (the lock) and 0.10.0, where the old signature gives the two [override] errors that fail build (3.14, unleash) on PRs that move the lock.
OpenFeatureClient.track calls provider.track(name, context, details), and
the no-op declared (event_name, event_details), so every client.track call
raised TypeError. It now takes the SDK's three arguments. The details stay
typed Any so the provider still type-checks against openfeature-sdk 0.8,
which has no TrackingEventDetails.
Closes#433
Signed-off-by: Simon Schrottner <simon.schrottner@flagsmith.com>
No actionable comments were generated in the recent review.
Walkthrough
UnleashProvider.track now accepts the OpenFeature tracking arguments. Its implementation remains a no-op. A test checks a three-argument call and verifies that the method returns None.
Changes: Unleash tracking
Layer / File(s)
Summary
Tracking signature and test providers/openfeature-provider-unleash/src/openfeature/contrib/provider/unleash/__init__.py, providers/openfeature-provider-unleash/tests/test_provider.py
track now accepts tracking_event_name, optional evaluation_context, and tracking_event_details of type Any. The method body remains unchanged. The added test passes three positional arguments and asserts that the method returns None.
The signature update addresses tracking calls raising TypeError while retaining unsupported tracking as a no-op. No merge-blocking issue is evident from the supplied changes; merge after normal checks pass.
Pre-merge checks: 5
Check name
Status
Explanation
Title check
The title names the fix and the affected component: the Unleash provider's track method now accepts the arguments that OpenFeatureClient.track passes. The changeset changes the track signature in Unle…
Description check
The description states the problem: UnleashProvider.track declared a two-argument signature, while OpenFeatureClient.track passes three arguments, so each client.track() call raised TypeError. It expl…
Linked Issues check
Issue #433 requires UnleashProvider.track to accept tracking_event_name, optional evaluation_context, and optional tracking_event_details, and to no-op. The reviewed implementation uses that t…
Out of Scope Changes check
The changes are limited to the UnleashProvider.track signature, its no-op implementation declaration, and a focused regression test. These changes directly implement issue #433.
Docstring Coverage
No eligible functions found in the changed files. Skipping docstring coverage check. Docstring coverage is scoped to functions touched by this diff with cyclomatic complexity of at least 2. Documentat…
Full details: Title check
Explanation
The title names the fix and the affected component: the Unleash provider's track method now accepts the arguments that OpenFeatureClient.track passes. The changeset changes the track signature in UnleashProvider and adds a test for it, so the title matches the main change. It is short, one sentence, and uses the conventional fix(scope) prefix.
Full details: Description check
Explanation
The description states the problem: UnleashProvider.track declared a two-argument signature, while OpenFeatureClient.track passes three arguments, so each client.track() call raised TypeError. It explains that the method now uses the SDK signature and stays a no-op, that details are typed Any for openfeature-sdk 0.8 compatibility, and that mypy and pytest were run under openfeature-sdk 0.8.4 and 0.10.0. This directly describes the changeset.
Full details: Linked Issues check
Explanation
Issue #433 requires UnleashProvider.track to accept tracking_event_name, optional evaluation_context, and optional tracking_event_details, and to no-op. The reviewed implementation uses that three-argument signature and returns None. The added test calls all three positional arguments and asserts None. The Any type preserves compatibility with the stated SDK versions.
Full details: Docstring Coverage
Explanation
No eligible functions found in the changed files. Skipping docstring coverage check. Docstring coverage is scoped to functions touched by this diff with cyclomatic complexity of at least 2. Documentation-only edits and deletions within surviving functions are included; unchanged diff context and fully deleted functions are excluded. Analyzed 0 functions across 2 files.
Finishing Touches
Generate docstrings
Commit to this branch
Create a new PR
Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts
CodeRabbit Verify
Run CodeRabbit Verify to test the changes in this pull request.
Recent review info
Run configuration
Source mode: Auto
Repository: Unavailable
Branch: Unavailable
File: No configuration file from this repository applied
Commit: Unavailable
Layers: Organization UI
Review profile: CHILL
Plan: Advanced
Run ID: b0161f52-c52d-4b96-9112-847928be9cdd
Commits
Reviewing files that changed from the base of the PR and between 2c1de0c and 01b504a.
Included review availability: This review used your included allowance. Your plan provides up to 1 included review per hour; 0 remain after this review.
✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 99.36%. Comparing base (b33d91c) to head (01b504a). ⚠️ Report is 3 commits behind head on main.
The lock has resolved 0.8.4 since 2025-12-09 while 0.9.0 and 0.10.0 have
shipped, so nothing in this repository has ever been tested against either.
Nothing pinned it there: every floor is a `>=`, every member is
`requires-python >=3.10`, and the lock carries no constraints -- renovate's
lock-file maintenance simply never picked the release up. `uv lock
--upgrade-package openfeature-sdk` moves 0.8.4 -> 0.10.0; the only other
change is the lock's stale openfeature-provider-flagd version, 0.5.2 -> 0.6.1.
Two behaviour changes reach the tests. Neither touches the flagd source,
which needs no change and stays clean under `poe mypy` on 26 files.
First, 0.10.0 made `set_provider` non-blocking, so a test that sets a
provider and evaluates on the next line now races initialisation and reads
PROVIDER_NOT_READY -- 20 failures across test_errors.py and test_metadata.py.
`set_provider_and_wait` restores the old blocking behaviour with one
difference that matters here: it re-raises whatever `initialize` raised,
where `set_provider` only dispatched PROVIDER_ERROR. Several of these
scenarios feed the provider a deliberately broken flag file, so that raise is
the scenario rather than a failure, hence the `contextlib.suppress`; it is
not papering over an unexpected error.
Second, 0.10.0 isolated event-handler dispatch onto a ThreadPoolExecutor
where 0.8.4 called handlers inline -- open-feature/python-sdk#599.
test_grpc_sync_fail_deadline read a flag set by a PROVIDER_ERROR handler on
the line after the call returned, which is now a race: `_run_initialize`
submits the event and then re-raises, and submit is not run. Rather than wait
on the handler, the assertion goes: it existed because the old `set_provider`
blocked and swallowed the error, leaving the event as the only way to observe
a failed init, and `pytest.raises(ProviderNotReadyError)` now carries that
claim directly. What the handler would assert today is that the SDK's
registry dispatches PROVIDER_ERROR when `initialize` raises -- SDK plumbing,
uniform across providers, and not this suite's to cover. The deadline
measurement it shared the test with is untouched, though it now has to wait
rather than time a call that would return immediately.
The other two handler-driven tests here -- test_invalid_flag_set_metadata and
the e2e event steps -- already poll with a timeout and need nothing.
The tests are the only thing that needs 0.10.0, so the floor goes in flagd's
dev group and the runtime floor stays at 0.8.2.
Measured on main 9a57dbb under Python 3.14: flagd's unit tests are 220
passed with this change on every repeated run, and `poe mypy` is clean.
tests/e2e needs docker and is left to CI. Unleash's `track` signature was
fixed separately in #474, which this branch no longer touches.
Signed-off-by: Simon Schrottner <simon.schrottner@flagsmith.com>
The lock has resolved 0.8.4 since 2025-12-09 while 0.9.0 and 0.10.0 have
shipped, so nothing in this repository has ever been tested against either.
Nothing pinned it there: every floor is a `>=`, every member is
`requires-python >=3.10`, and the lock carries no constraints -- renovate's
lock-file maintenance simply never picked the release up. `uv lock
--upgrade-package openfeature-sdk` moves 0.8.4 -> 0.10.0; the only other
change is the lock's stale openfeature-provider-flagd version, 0.5.2 -> 0.6.1.
Two behaviour changes reach the tests. Neither touches the flagd source,
which needs no change and stays clean under `poe mypy` on 26 files.
First, 0.10.0 made `set_provider` non-blocking, so a test that sets a
provider and evaluates on the next line now races initialisation and reads
PROVIDER_NOT_READY -- 20 failures across test_errors.py and test_metadata.py.
`set_provider_and_wait` restores the old blocking behaviour with one
difference that matters here: it re-raises whatever `initialize` raised,
where `set_provider` only dispatched PROVIDER_ERROR. Several of these
scenarios feed the provider a deliberately broken flag file, so that raise is
the scenario rather than a failure, hence the `contextlib.suppress`; it is
not papering over an unexpected error.
Second, 0.10.0 isolated event-handler dispatch onto a ThreadPoolExecutor
where 0.8.4 called handlers inline -- open-feature/python-sdk#599.
test_grpc_sync_fail_deadline read a flag set by a PROVIDER_ERROR handler on
the line after the call returned, which is now a race: `_run_initialize`
submits the event and then re-raises, and submit is not run. Rather than wait
on the handler, the assertion goes: it existed because the old `set_provider`
blocked and swallowed the error, leaving the event as the only way to observe
a failed init, and `pytest.raises(ProviderNotReadyError)` now carries that
claim directly. What the handler would assert today is that the SDK's
registry dispatches PROVIDER_ERROR when `initialize` raises -- SDK plumbing,
uniform across providers, and not this suite's to cover. The deadline
measurement it shared the test with is untouched, though it now has to wait
rather than time a call that would return immediately.
The other two handler-driven tests here -- test_invalid_flag_set_metadata and
the e2e event steps -- already poll with a timeout and need nothing.
The tests are the only thing that needs 0.10.0, so the floor goes in flagd's
dev group and the runtime floor stays at 0.8.2.
Measured on main 9a57dbb under Python 3.14: flagd's unit tests are 220
passed with this change on every repeated run, and `poe mypy` is clean.
tests/e2e needs docker and is left to CI. Unleash's `track` signature was
fixed separately in #474, which this branch no longer touches.
Signed-off-by: Simon Schrottner <simon.schrottner@flagsmith.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
UnleashProvider.trackdeclared(event_name, event_details), butOpenFeatureClient.trackcalls it with(name, context, details), so everyclient.track()raisedTypeError. It now takes the SDK's signature and stays a no-op. The details are typedAnyso it still type-checks against openfeature-sdk 0.8.Checked with mypy and pytest under openfeature-sdk 0.8.4 (the lock) and 0.10.0, where the old signature gives the two
[override]errors that failbuild (3.14, unleash)on PRs that move the lock.Closes #433
🤖 Generated with Claude Code