[ketanmixpanel]

Summary

SDK-448: $experiment_started exposures fired through the Mixpanel OpenFeature provider now include "$openfeature_provider": true, so OpenFeature usage can be told apart from direct SDK flag calls. Direct SDK calls are unchanged (no property).

No public API change: no new public methods, parameters or fields. The provider signals the SDK through an argument it already passes on every evaluation.

How

• Provider: adds "$openfeature_provider": true to the evaluation context it already passes to getVariant, set after the customer attributes so a same-named attribute cannot override it.
• SDK: the exposure-tracking code (which already receives the context to read distinct_id) copies the marker onto $experiment_started when the context value is exactly true. Covers local and remote evaluation.
• Local evaluation is unaffected: it only reads the flag assignment key, distinct_id and custom_properties.

Testing

• New SDK tests: local, remote sync and remote async; marker present tags the exposure, absent does not. The manual track_exposure_event methods also honour the marker since they receive a context.
• Provider tests: exact-context assertions updated to include the marker; new tests that it is always present and cannot be overridden by a same-named attribute.
• pytest (SDK): 393 passed. Provider: 57 passed.
• ruff check: no new errors (19 SDK / 3 provider, all pre-existing).

Note: marker is sent to the server on remote evaluation

Because the marker lives in the evaluation context, remote evaluation sends it to /flags with the rest of the context. The flags API accepts and ignores it (checked in analytics/go/src/mixpanel.com/flags/api/handlers/evaluatefeatureflags.go):

• request validation only type-checks distinct_id and device_id;
• evaluation only reads the assignment key, distinct_id/device_id, custom_properties and hierarchical group IDs;
• logRequest does not log it.

So it has no effect on targeting, rollout or variant assignment; it is only visible in the GET context query parameter.

Release order

Older SDKs ignore the marker, so the provider change is safe on its own (no errors; the property just does not appear). The property appears once customers run an SDK release containing this change; the provider minimum SDK version was intentionally not bumped here and should be raised after the SDK release. No version or changelog edits.

🤖 Generated with Claude Code

[linear-code]

SDK-448

[greptile-apps]

Confidence Score: 5/5

[Medium impact] The PR appears safe to merge.

_{Reviews (1) · Last reviewed commit: "feat: tag OpenFeature exposures with $op..." · Reviewed by Greptile}

[codecov]

Codecov Report

❌ Patch coverage is 98.55072% with 1 line in your changes missing coverage. Please review.
✅ Project coverage is 96.51%. Comparing base (091b056) to head (f4e2da5).

Files with missing lines	Patch %	Lines
mixpanel/flags/test_remote_feature_flags.py	95.65%	0 Missing and 1 partial ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##           master     #202      +/-   ##
==========================================
+ Coverage   96.39%   96.51%   +0.11%     
==========================================
  Files          15       15              
  Lines        2888     2955      +67     
  Branches      176      180       +4     
==========================================
+ Hits         2784     2852      +68     
+ Misses         67       66       -1     
  Partials       37       37              

Flag	Coverage Δ
openfeature-provider	51.66% <72.00%> (+0.42%)	⬆️

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.