| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
…plan Resolves feast-dev#6104 Three gaps existed in the plan-mode versioning flow: 1. FeatureViewPinConflict was never raised during `feast plan` — the check only ran inside apply_feature_view. Users could not discover pin conflicts until after running `feast apply`. 2. The `version` spec field was compared as a raw proto string in diff_registry_objects, producing unhelpful output like "latest -> v2". The resolved numeric pin target (from meta.current_version_number) was never shown. 3. No tests covered plan-mode behaviour for versioned feature views. Changes: - BaseRegistry.check_version_pin_conflict(): new read-only method that mirrors the conflict detection in apply_feature_view. Uses get_feature_view_by_version and get_any_feature_view (both available on BaseRegistry) so it works for both file and SQL registries without duplicating per-registry logic. - store.plan(): calls check_version_pin_conflict for every feature view (FeatureView, StreamFeatureView, OnDemandFeatureView) in the desired repo contents, surfacing conflicts before apply runs. - diff_registry_objects(): excludes `version` from the generic spec field loop (added to FIELDS_TO_IGNORE) and adds a dedicated version display block that reads meta.current_version_number for the current state, producing output like "v2 (pin) -> v1 (pin)" or "v1 (pin) -> latest". - 8 new unit tests across TestCheckVersionPinConflict and TestVersionDiffDisplay covering: latest-version no-op, forward declarations, schema-only changes, pin+schema conflicts, pin display, unpin display, and plan-loop wiring. Signed-off-by: Abhishek8108 <87538407+Abhishek8108@users.noreply.github.com>
|
The unit-test-python (3.12, macos-14) failure appears to be a pre-existing macOS subprocess flake unrelated to this PR. Failing test: test_cli_apply_duplicated_featureview_names
This is the same pattern as the test_e2e_local macOS flake seen in past PRs. Could someone please trigger a re-run when you get a chance? Thanks! |
Sorry, something went wrong.
| Back | FazBrowse Home | New Git URL |
Summary
Closes #6104
Three gaps existed in the plan-mode versioning flow introduced by #6101:
1. FeatureViewPinConflict never raised during feast plan
The conflict check (simultaneous version pin + schema change) only ran inside apply_feature_view(). Users had no way to discover pin conflicts without running feast apply — defeating the purpose of plan mode.
2. Version changes not visible in plan output
diff_registry_objects iterated over spec fields and compared version as a raw proto string ("latest" -> "v2"). The resolved numeric pin target from meta.current_version_number was never surfaced, so users could not see which numeric version they were pinning to or from.
3. No tests for plan-mode versioning
No unit tests covered either of the above.
Changes
BaseRegistry.check_version_pin_conflict() (new method)
Read-only plan-time guard that mirrors the conflict detection inside apply_feature_view. Implemented on BaseRegistry using get_feature_view_by_version and get_any_feature_view — both already declared on BaseRegistry — so it works for both file and SQL registries without duplicating per-registry logic.
Conflict condition: user is simultaneously pinning to an existing version AND the feature view definition differs from the active version (schema or UDF change).
store.plan() — calls the conflict check
Iterates all feature views (FeatureView, StreamFeatureView, OnDemandFeatureView) in desired_repo_contents and calls registry.check_version_pin_conflict() for each, surfacing FeatureViewPinConflict before feast apply runs.
diff_registry_objects() — human-readable version display
Updated feature_view driver_stats version: latest -> v2 (pin) Updated feature_view orders version: v1 (pin) -> latestTest plan