UnleashProvider.track has the wrong signature: client.track raises TypeError instead of no-op

Open Beginner friendly
#433 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
2/5
Estimated time
1-3 hours
Newbie friendliness
88/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
python
Domain
api

Research direction

Start in providers/openfeature-provider-unleash/src/openfeature/contrib/provider/unleash/init.py at UnleashProvider.track and compare it with the FeatureProvider signature. Review tests/test_provider.py and add coverage for api.get_client().track("my-event") with the provider; done means the call no longer raises TypeError and the provider remains a no-op.

Written by the indexing model from the issue text.

Description

bug
Summary

UnleashProvider.track() declares a narrower signature than the one OpenFeatureClient.track calls, so any client.track(...) call raises TypeError instead of no-opping.

Details

openfeature-sdk 0.9.0 added tracking. OpenFeatureClient.track dispatches with three positional arguments:

self.provider.track(tracking_event_name, merged_eval_context, tracking_event_details)

The provider's no-op takes two (unleash/__init__.py):

def track(self, event_name: str, event_details: dict | None = None) -> None:
    """No-op tracking method. ..."""
    return None

Requirement 6.1.1 says the client's track MUST be a no-op when the provider does not implement tracking — so the method that exists to satisfy that is the thing breaking it.

Reproduction
from openfeature import api
from openfeature.contrib.provider.unleash import UnleashProvider

provider = UnleashProvider(url="http://localhost:4242/api", app_name="repro", api_token="token")
api.set_provider(provider)
api.get_client().track("my-event")
TypeError: UnleashProvider.track() takes from 2 to 3 positional arguments but 4 were given

Reproduced against openfeature-provider-unleash at main with openfeature-sdk 0.10.0.

Why it has gone unnoticed

The workspace uv.lock still resolves openfeature-sdk 0.8.4, which has no tracking API at all, so CI never exercises this path. A released install does: the package declares openfeature-sdk>=0.8.2, so a fresh pip install openfeature-provider-unleash resolves 0.10.0 and the call raises.

mypy reports it as two [override] errors as soon as the SDK moves to 0.9.0+:

src/openfeature/contrib/provider/unleash/__init__.py:139: error: Signature of "track" incompatible with supertype "openfeature.provider.AbstractProvider"  [override]
src/openfeature/contrib/provider/unleash/__init__.py:139: error: Signature of "track" incompatible with supertype "openfeature.provider.FeatureProvider"  [override]

The existing assert hasattr(provider, "track") in tests/test_provider.py cannot catch it — it holds either way.

Affected versions

openfeature-provider-unleash at every released version, when paired with openfeature-sdk >= 0.9.0.

Fix

Match FeatureProvider.track(tracking_event_name, evaluation_context=None, tracking_event_details=None). (AbstractProvider.track is already a no-op with that signature, so deleting the override also works, but only at 0.9.0+.)

Dominant language
Python
Stars
27
Forks
33
Avg merge
5h
Merged PRs (30d)
10

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from open-feature/python-sdk-contrib

All issues in open-feature/python-sdk-contrib

Similar issues

More Python issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.