fix: Surface FeatureViewPinConflict and version changes during feast plan by Abhishek8108 · Pull Request #6391 · feast-dev/feast

…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>