Context

PR #5803 adds a new argument on_demand_feature_views to Provider.get_historical_features.

This fixes a gap where FeatureStore.get_historical_features() already resolves which OnDemandFeatureViews are requested (via _group_feature_refs), but historically that list was not explicitly passed to the Provider. Some provider implementations / compute engines benefit from receiving the requested ODFVs explicitly (planning/optimization/correctness without re-deriving).

A maintainer requested tracking this as an interim change and flagging a proper long-term interface fix.

Problem

The historical retrieval interface currently encourages “API drift”:

• FeatureStore performs grouping/selection of requested feature views vs ODFVs
• Providers/offline stores may need to re-derive ODFV selection from feature_refs and registry state
• New requirements tend to be implemented via ad-hoc argument additions to Provider.get_historical_features

This makes the contract unclear and can lead to duplicated logic or unnecessary work in providers.

Goal

Define a clearer long-term contract for historical retrieval that:

• makes the retrieval request structure explicit (including requested ODFVs / transformations)
• avoids one-off arguments in the Provider API
• reduces duplicated grouping/selection logic between FeatureStore and providers
• supports compute-engine-style providers planning execution deterministically

Proposed direction (non-binding)

One of:

1. Introduce a typed request object (e.g. HistoricalRetrievalRequest) passed into Provider/offline store, containing:
   • resolved FeatureViews
   • resolved OnDemandFeatureViews / transformations
   • feature_refs
   • entity dataframe/query or time range params
   • full_feature_names, project/config, etc.
2. Alternatively, formalize that feature_views includes both FVs and ODFVs in a consistent way, and remove the need for a separate on_demand_feature_views parameter (with a documented contract for how they’re represented and used).

Acceptance criteria

• API: A documented, stable Provider/offline-store historical retrieval interface (request object or equivalent).
• Refactor: Avoid future ad-hoc args like on_demand_feature_views being added to Provider.get_historical_features.
• Compat: Clear backward compatibility / deprecation plan for existing providers.
• Tests: Unit/integration coverage proving:
  • requested ODFVs are correctly resolved and passed through
  • providers can plan execution without re-deriving ODFV selection

Related

• PR: feat: Pass requested On-Demand Feature Views to Provider get_historical_features #5803