feat: Version-pinning for FeatureService (online + offline) by HSarwat · Pull Request #6718 · feast-dev/feast

HSarwat · 2026-08-09T20:51:39Z

Closes #6717.
Related to #6389 (feature versioning in offline retrieval).

What

Lets a FeatureService pin a specific historical FeatureView / OnDemandFeatureView version, honored by both get_online_features and get_historical_features. Feast's docs currently list this as a known limitation ("Feature services always resolve to the active (promoted) version"); this closes that gap.

Commits

fix: Pin FeatureView version in FeatureService projections — stamp projection.version_tag from the source view's version in FeatureService.__init__; read projection.version_tag (instead of None) in utils._get_feature_views_to_use. version="latest" is unaffected.
feat: Support string feature references in FeatureService — features accepts "<fv>[@<version>][:<feature>]" strings, resolved once in FeatureStore.apply via FeatureService.resolve_pending_refs. Factors _parse_feature_or_view_ref out of _parse_feature_ref (optional :feature).
fix: Resolve version-pinned OnDemandFeatureViews in offline retrieval — shared utils._get_requested_on_demand_feature_views used by all three unversioned ODFV call sites; pinned ODFV refs now resolve to the pinned snapshot offline. This is the offline-retrieval versioning gap tracked in Proposal: Version-qualified feature refs in get_historical_features (offline store versioning) #6389.
docs: Document FeatureService version pinning — alpha versioning page + enable_online_feature_view_versioning docstring clarified to note it gates offline too; Known Limitations updated.

Problem

Building a service from a version-pinned FeatureView silently falls back to the promoted version:

fv  = FeatureView(name="driver_stats", version="v2", ...)
svc = FeatureService(name="model_v1", features=[fv[["conv_rate"]]])
svc.feature_view_projections[0].version_tag    # -> None   (should be 2)
svc.feature_view_projections[0].name_to_use()  # -> "driver_stats"  (should be "driver_stats@v2")

Two bugs cause this: FeatureService.__init__ never translates the view's version string into projection.version_tag, and utils._get_feature_views_to_use hard-codes the version as None for the FeatureService branch. A related pre-existing bug (#6389) breaks offline retrieval of version-pinned OnDemandFeatureViews: offline stores re-fetch ODFVs via an unversioned registry.list_on_demand_feature_views, so a pinned ODFV ref raises ValueError: Could not find feature view from reference ... or silently drops features across every offline backend.

Design notes for reviewers

Priority ordering (commit 2): a pinned string ref always resolves from registry.get_feature_view_by_version, never from fvs_to_update (the apply batch only ever holds "latest" objects and would substitute the wrong schema). Covered by test_pinned_ref_ignores_fvs_to_update.
Backward compatible: unversioned refs / version="latest" behave exactly as before; every existing (unversioned) FeatureService is unaffected.
Flag name: enable_online_feature_view_versioning is misleadingly scoped to "online" — it gates both paths. Clarified in the docstring/docs here rather than renamed (rename would be a breaking config change; happy to follow up if maintainers prefer).

Tests

New unit tests: test_feature_service_versioning.py (object + string-ref pinning, proto round-trip, backward compat, error guards, priority ordering) and test_odfv_offline_versioning.py (version-aware ODFV resolution, v0 fallback, non-ODFV skip, dedup). All pass; ruff (0.16.0) + mypy clean on changed files.

codecov-commenter · 2026-08-10T13:27:07Z

⚠️ Please install the to ensure uploads and comments are reliably processed by Codecov.

Codecov Report

❌ Patch coverage is 91.11111% with 8 lines in your changes missing coverage. Please review.
✅ Project coverage is 46.99%. Comparing base (5fd7af7) to head (cc4bcce).

Files with missing lines	Patch %	Lines
sdk/python/feast/utils.py	86.66%	2 Missing and 4 partials ⚠️
sdk/python/feast/feature_service.py	95.00%	0 Missing and 2 partials ⚠️
❗ Your organization needs to install the Codecov GitHub app to enable full functionality.

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #6718      +/-   ##
==========================================
+ Coverage   46.92%   46.99%   +0.07%     
==========================================
  Files         416      416              
  Lines       50549    50620      +71     
  Branches     7252     7270      +18     
==========================================
+ Hits        23718    23789      +71     
+ Misses      25157    25156       -1     
- Partials     1674     1675       +1

Flag	Coverage Δ
go-feature-server	`30.58% <ø> (ø)`
python-unit	`48.33% <91.11%> (+0.07%)`	⬆️

Files with missing lines	Coverage Δ
sdk/python/feast/feature_store.py	`42.99% <100.00%> (+0.03%)`	⬆️
sdk/python/feast/infra/offline_stores/dask.py	`53.30% <ø> (ø)`
...python/feast/infra/offline_stores/offline_utils.py	`67.52% <100.00%> (ø)`
sdk/python/feast/on_demand_feature_view.py	`71.27% <100.00%> (-0.31%)`	⬇️
sdk/python/feast/repo_config.py	`78.72% <100.00%> (ø)`
sdk/python/feast/feature_service.py	`85.05% <95.00%> (+2.77%)`	⬆️
sdk/python/feast/utils.py	`78.38% <86.66%> (+0.50%)`	⬆️

... and 1 file with indirect coverage changes

Continue to review full report in Codecov by Harness.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 5fd7af7...cc4bcce. Read the comment docs.

🚀 New features to boost your workflow:

❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

ntkathole · 2026-08-11T03:55:50Z

@HSarwat Please fix CI

HSarwat · 2026-08-12T04:26:16Z

@ntkathole This PR doesnt introduce any dependency change, yet the CI is failing because it cant resolve greenlet 3.5.5 . I am not really sure where the error is coming from.

Rebased my PR with the latest changed from main in case this error was resolved in a later commit and to trigger the CI again

A FeatureService built from a version-pinned FeatureView (e.g. FeatureView(version="v2")) silently served the promoted version instead of the pinned one, defeating the guarantee a FeatureService is meant to provide. Two bugs caused this: 1. FeatureService.__init__ appended the source view's projection without translating its `version` string into `projection.version_tag` (the field name_to_use() checks to render "fv@v2"). 2. utils._get_feature_views_to_use hard-coded the version as None for the FeatureService branch, so retrieval always fell through to the promoted snapshot. Stamp version_tag from the source view's version in __init__, and read projection.version_tag (instead of None) during retrieval. The default version ("latest") leaves version_tag as None, so every existing unversioned FeatureService is unaffected. Covers both online and offline retrieval, which share _get_feature_views_to_use. Signed-off-by: h-sarwat <hussein_sarwat@yahoo.com>

FeatureService.features now accepts string refs using the same '<feature_view>[@<version>][:<feature>]' syntax as get_historical_features/get_online_features, e.g. "driver_stats@v2" or "driver_stats@v2:trips_today". This lets a service pin a historical FeatureView version without importing or reconstructing the underlying object. String entries are stashed at construction (no registry is available then) and resolved once, in FeatureStore.apply/plan, via a new FeatureService.resolve_pending_refs. A pinned ref always resolves from the registry snapshot for that version; an unversioned ref prefers the apply batch, then the promoted version. utils._parse_feature_ref is refactored onto a new _parse_feature_or_view_ref that makes the ':<feature>' suffix optional (whole-view refs); _parse_feature_ref is unchanged for existing callers. Signed-off-by: h-sarwat <hussein_sarwat@yahoo.com>

Offline stores re-fetch OnDemandFeatureViews from the registry independently of the version-aware online path, using an unversioned registry.list_on_demand_feature_views. A version-pinned ODFV (e.g. from a FeatureService pinning a specific ODFV version) therefore either raised "Could not find feature view from reference odfv@v1:feat" or silently served the promoted version during get_historical_features. Add a shared utils._get_requested_on_demand_feature_views that resolves each ref version-aware — pinned refs via get_feature_view_by_version (stamping projection.version_tag so name_to_use() matches downstream), unversioned refs via the promoted list as before. Route the three unversioned call sites through it: OnDemandFeatureView.get_requested_odfvs, offline_utils.get_feature_view_query_context, and dask.py's inline duplicate. This covers every offline backend, which all funnel through one of those. Unversioned refs are unchanged. Signed-off-by: h-sarwat <hussein_sarwat@yahoo.com>

Document pinning a historical feature view version inside a FeatureService, via both string feature refs ("driver_stats@v2:trips_today") and version-pinned FeatureView objects, on the alpha feature-view-versioning page. Clarify that enable_online_feature_view_versioning gates both online and offline versioned resolution (they share one code path), both in the page and in the RegistryConfig field docstring. Update Known Limitations: offline version-qualified retrieval and version-pinned feature services are now supported. Signed-off-by: h-sarwat <hussein_sarwat@yahoo.com>

HaoXuAI

String refs introduce an unresolved lifecycle state that retrieval and serialization do not handle. A freshly constructed FeatureService(name="svc", features=["driver_stats@v2:conv_rate"]) has no projections until apply/plan. Passing that object directly to get_online_features or get_historical_features is a supported Feast pattern, but _get_features() consults the registered service while _get_feature_views_to_use() consumes the unresolved passed object, producing inconsistent resolution; to_proto() before apply also silently serializes an empty service.

Please either resolve the passed service from the registry in all retrieval paths, or reject unresolved services with a clear error. Add an integration-style test that reconstructs the string-based FeatureService in a fresh process after apply and passes that object to both online and historical retrieval.

HSarwat · 2026-08-16T19:53:54Z

@HaoXuAI

I resolved the passed FeatureService from the registry in _get_feature_views_to_use when it has unresolved string refs, so it matches what _get_features already does and both retrieval paths agree instead of one seeing empty projections.

Also added an integration test in test_versioning.py that reconstructs the string-ref service in a fresh store after apply and passes it to both online and historical retrieval.

HaoXuAI

LGTM

ntkathole

Thanks for the follow-up on the unresolved string-ref retrieval path — that looks correct.

A few remaining issues that I think should land before merge:

Object-based pinning mutates the source FeatureView's projection (string-ref path already copies).
Recommended string refs cannot resolve an ODFV created in the same apply (fvs_to_update_map only includes odfvs_to_write).
prepare_for_apply / to_proto() still treat an unresolved string-ref service as a valid empty service (all([]) is True).

Inline comments have details. Would also like one integration test that actually pins v0 vs a later v1 and asserts retrieval, not only the unversioned reconstructed-service path.

ntkathole · 2026-08-18T03:44:27Z

+                if projection.version_tag is None and fv_version:
+                    is_latest, version_num = parse_version(fv_version)
+                    if not is_latest:
+                        projection.version_tag = version_num


This mutates the source FeatureView's own projection. FeatureView(version="v2") does not set projection.version_tag itself, so after FeatureService(features=[fv]) the caller's fv.projection.version_tag becomes 2.

Online table naming (compute_versioned_name) reads that field, so a later materialize/get on the same object can unexpectedly hit *_v2. The string-ref path already copy.copys for this reason — please copy here too before stamping version_tag.

ntkathole · 2026-08-18T03:44:27Z

        for feature_service in feature_services_to_update:
+            # Resolve string feature refs (e.g. "driver_stats@v2") before
+            # inference. No-op for object-only services.
+            feature_service.resolve_pending_refs(


fvs_to_update_map only includes odfvs_to_write (write_to_online_store=True). A normal ODFV is absent, and _make_inferences runs before apply_feature_view, so the registry lookup fails too.

The docs recommend string refs, but this fails:

odfv = on_demand_feature_view(...)(src_fv) svc = FeatureService(name="svc", features=["my_odfv"]) store.apply([src_fv, odfv, svc]) # FeatureViewNotFound

Object form features=[odfv] still works. Please pass odfvs_to_update (not just odfvs_to_write) into resolve_pending_refs.

ntkathole · 2026-08-18T03:44:27Z

+    ) -> None:
+        """Resolve string feature refs (see ``__init__``) into projections.
+
+        Called automatically by ``FeatureStore.apply``/``plan`` so the pin is


Docstring says apply/plan resolve these refs, but prepare_for_apply does not call resolve_pending_refs, and its early return is if self._features and all(p.features for p in self.feature_view_projections).

all([]) is True, so a service with only string refs and empty projections returns immediately. to_proto() then serializes zero features.

FeatureStore.apply happens to call this first, so the happy path is OK. Direct registry.apply_feature_service(...) or any proto round-trip before apply will persist an empty service with no error.

Please reject (or resolve) unresolved _pending_feature_refs in prepare_for_apply and to_proto().

HSarwat requested review from a team as code owners August 9, 2026 20:51

HSarwat requested review from ejscribner, robhowley and tokoko and removed request for a team August 9, 2026 20:51

HSarwat force-pushed the feat/feature-service-version-pinning branch from bc41ab7 to 6083f35 Compare August 12, 2026 04:11

HSarwat added 4 commits August 14, 2026 10:44

ntkathole force-pushed the feat/feature-service-version-pinning branch from 6083f35 to 573931b Compare August 14, 2026 05:14

ntkathole added the ok-to-test label Aug 14, 2026

HaoXuAI requested changes Aug 16, 2026

View reviewed changes

HSarwat added 2 commits August 16, 2026 21:37

fix: Handle unresolved string-ref services in feature service retrieval

3083b97

test: Add integration tests for string-ref FeatureService retrieval

1400657

Merge branch 'master' into feat/feature-service-version-pinning

18239cc

HaoXuAI self-requested a review August 16, 2026 22:17

Merge branch 'master' into feat/feature-service-version-pinning

cc4bcce

HaoXuAI approved these changes Aug 18, 2026

View reviewed changes

ntkathole requested changes Aug 18, 2026

View reviewed changes

Navigation Menu

Uh oh!

feat: Version-pinning for FeatureService (online + offline) - #6718

feat: Version-pinning for FeatureService (online + offline)#6718
HSarwat wants to merge 8 commits into
feast-dev:masterfrom
HSarwat:feat/feature-service-version-pinning

HSarwat commented Aug 9, 2026

Uh oh!

codecov-commenter commented Aug 10, 2026 •

edited

Loading

Uh oh!

ntkathole commented Aug 11, 2026

Uh oh!

HSarwat commented Aug 12, 2026 •

edited

Loading

Uh oh!

HaoXuAI left a comment

Uh oh!

HSarwat commented Aug 16, 2026

Uh oh!

HaoXuAI left a comment

Uh oh!

ntkathole left a comment

Uh oh!

ntkathole Aug 18, 2026

Uh oh!

ntkathole Aug 18, 2026

Uh oh!

ntkathole Aug 18, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

Uh oh!

Conversation

HSarwat commented Aug 9, 2026

What

Commits

Problem

Design notes for reviewers

Tests

Uh oh!

codecov-commenter commented Aug 10, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Codecov Report

Uh oh!

ntkathole commented Aug 11, 2026

Uh oh!

HSarwat commented Aug 12, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

HaoXuAI left a comment

Choose a reason for hiding this comment

Uh oh!

HSarwat commented Aug 16, 2026

Uh oh!

HaoXuAI left a comment

Choose a reason for hiding this comment

Uh oh!

ntkathole left a comment

Choose a reason for hiding this comment

Uh oh!

ntkathole Aug 18, 2026

Choose a reason for hiding this comment

Uh oh!

ntkathole Aug 18, 2026

Choose a reason for hiding this comment

Uh oh!

ntkathole Aug 18, 2026

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

codecov-commenter commented Aug 10, 2026 •

edited

Loading

HSarwat commented Aug 12, 2026 •

edited

Loading