Fix bug causing OnDemandFeatureView.infer_features() to fail when the…

[ArrichM]

What this PR does / why we need it:
Problem:
When running OnDemandFeatureView.infer_features() and there are features registered with labels, an RegistryInferenceFailure is raised.

Currently, this will work as-is:

import feast
import pandas as pd

@feast.on_demand_feature_view.on_demand_feature_view(
    inputs={},
    features=[
        feast.Feature(name="not_labeled", dtype=feast.ValueType.DOUBLE)
    ],
)
def not_labeled_view(feature_df: pd.DataFrame) -> pd.DataFrame:
    df = pd.DataFrame(dtype="float", columns=["not_labeled"])
    return df

not_labeled_view.infer_features()

While this won't:

import feast
import pandas as pd

@feast.on_demand_feature_view.on_demand_feature_view(
    inputs={},
    features=[
        feast.Feature(name="not_labeled", dtype=feast.ValueType.DOUBLE, labels={"test": "label"})
    ],
)
def labeled_view(feature_df: pd.DataFrame) -> pd.DataFrame:
    df = pd.DataFrame(dtype="float", columns=["labeled"])
    return df

labeled_view.infer_features()

Suggested Fix:
To allow features with labels in the OnDemandFeatureView definition, remove labels from the registered features when comparing infered features with registered ones.

Do not include labels when checking equality of Features.

Does this PR introduce a user-facing change?:

None

[feast-ci-bot]

@ArrichM: Adding the "do-not-merge/release-note-label-needed" label because no release-note block was detected, please follow our release note process to remove it.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[feast-ci-bot]

Hi @ArrichM. Thanks for your PR.

I'm waiting for a feast-dev member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[adchia]

/ok-to-test

[codecov-commenter]

Codecov Report

Merging #2046 (e1017ac) into master (dc46a96) will decrease coverage by 0.29%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##           master    #2046      +/-   ##
==========================================
- Coverage   83.70%   83.41%   -0.30%     
==========================================
  Files         100      100              
  Lines        8028     8029       +1     
==========================================
- Hits         6720     6697      -23     
- Misses       1308     1332      +24     

Flag	Coverage Δ
integrationtests	74.16% <100.00%> (-0.30%)	⬇️
unittests	57.54% <0.00%> (-0.01%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files	Coverage Δ
sdk/python/feast/on_demand_feature_view.py	95.04% <100.00%> (+0.04%)	⬆️
sdk/python/feast/infra/aws.py	72.59% <0.00%> (-11.06%)	⬇️
.../integration/online_store/test_universal_online.py	97.67% <0.00%> (-0.47%)	⬇️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update dc46a96...e1017ac. Read the comment docs.

[achals]

Thanks for the PR @ArrichM! I think your approach would work, but I'm wondering if a better fix would be to update https://github.com/feast-dev/feast/blob/master/sdk/python/feast/feature.py#L50 and remove the line

            or self.labels != other.labels

Since that would fix these kinds of comparisons more generally. What do you think?

[ArrichM]

Yes, that was also what I came up with originally, but then I was hesitant to introduce this change globally.

[achals]

/lgtm

[feast-ci-bot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: achals, ArrichM

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [achals]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment