| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
…ine store The Dask offline store sorted by created_timestamp_column and then by timestamp_field in a second pass, relying on that second sort to keep the created timestamp order for rows sharing an event timestamp. sort_values is not stable, so with enough rows the older row could end up last and win the keep="last" deduplication, both in historical retrieval and in pull_latest_from_table_or_query. Sort once by [timestamp_field, created_timestamp_column] instead. Signed-off-by: LuisFigueroaG <luis.h.figueroa.g@gmail.com>
|
⚠️ Please install the Codecov Report❌ Patch coverage is 90.90909% with 1 line in your changes missing coverage. Please review.
@@ Coverage Diff @@
## master #6952 +/- ##
=======================================
Coverage 49.04% 49.05%
=======================================
Files 433 433
Lines 54308 54304 -4
Branches 7910 7908 -2
=======================================
+ Hits 26637 26640 +3
+ Misses 25790 25785 -5
+ Partials 1881 1879 -2
... and 1 file with indirect coverage changes Continue to review full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
Sorry, something went wrong.
| Back | FazBrowse Home | New Git URL |
What this PR does / why we need it:
When two rows share an event timestamp, Feast is supposed to keep the one with the latest created_timestamp_column. The Dask offline store did this with two consecutive sorts, first by the created timestamp and then by the event timestamp, and relied on the second sort preserving the order of the first:
Dask's sort_values (and pandas' default quicksort) is not stable, so for tied event timestamps the older row can end up last and win drop_duplicates(keep="last"). With 300 entities, each having two rows with the same event timestamp, 291 came back with the older row. A single partition with 20 entities already returned 12 wrong rows. This affects get_historical_features (_drop_duplicates) and pull_latest_from_table_or_query (evaluate_offline_job).
This sorts once by [timestamp_field, created_timestamp_column] in both places, including the ZeroDivisionError fallbacks. Multi-column sort_values is supported by dask since well before the dask>=2024.2.1 minimum.
Which issue(s) this PR fixes:
No existing issue.
Checks
Testing Strategy
Added test_dask_created_timestamp_tiebreak.py, covering get_historical_features and pull_latest_from_table_or_query with 100 entities across 4 partitions. Both tests failed in 5 out of 5 runs on master and pass with this change. ruff format --check, ruff check and mypy pass on the changed files, and sdk/python/tests/unit/infra/offline_stores/ passes (291 passed).