Expected Behavior

get_historical_features() should return exactly one output row per row in the input entity_df, regardless of whether some rows share a join key and event timestamp with other rows. Two entity_df rows with the same (join key, timestamp) but different other columns are distinct requests, not duplicates - e.g. two orders placed by the same customer in the same logged second.

Current Behavior

On the Dask/File offline store, entity_df rows that share a join key and event timestamp are silently collapsed into one, discarding every other column of the dropped rows (labels, order ids, anything the caller attached to the request).

The DuckDB offline store, and every SQL-based offline store (BigQuery, Snowflake, Redshift, Postgres, Spark, ClickHouse, Trino, Couchbase, Athena), already avoid this by carrying a per-row "entity_row_unique_id" through their generated queries. Dask/File has no equivalent, so it is the only backend where this data loss happens.

Steps to reproduce

Build an entity_df with 3 rows for get_historical_features: two rows share the same join key and event_timestamp but have different values in another column (e.g. an order_id and a label), and a third row is a different entity. Call get_historical_features() against a Dask/File-backed FeatureStore. The result has only 2 rows - one of the two same-timestamp rows is missing along with its order_id and label. Running the identical entity_df against a DuckDB-backed offline store returns all 3 rows correctly.

Specifications

• Version: master
• Platform: any (Dask/File offline store specifically; DuckDB and SQL-based stores are unaffected)
• Subsystem: offline store / historical retrieval

Possible Solution

Tag each entity_df row with a synthetic unique id before the per-feature-view join in dask.py, and deduplicate on that id instead of (join keys, event timestamp) - mirroring the entity_row_unique_id technique already used by the SQL-based offline stores. Submitted as a PR alongside this issue.

FIX:- #6786