GV

GeezerVison

The World Wide Web, restored to 800 pixels of glory.

Home|About|Gaming cabinet|Archives|How it works|Starter sites

On this site

  • Sign in
  • ActionsCI/CD and automation
  • CodespacesCloud development environments
  • All Features
  • Documentation
  • Training
  • Certifications
  • Build with Copilot
  • Customize Copilot
  • Integrations
  • Trending repos
  • GitHub Sponsors
  • Developer articles
  • Enterprises

This view

  • Original page
  • New address

GeezerVison is showing github.com — Bug: UserWarning when passing `FeatureService` object to both `apply()` and `get_online_features()` - Caused by difference in `FeatureViewProjection.from_proto()` and `FeatureViewProjection.from_definition()` · Issue #4030 · feast-dev/feast

Bug: UserWarning when passing FeatureService object to both apply() and get_online_features() - Caused by difference in FeatureViewProjection.from_proto() and FeatureViewProjection.from_definition() #4030

New issue
Copy link
New issue
Copy link
Closed
#4116
Closed
Bug: UserWarning when passing FeatureService object to both apply() and get_online_features() - Caused by difference in FeatureViewProjection.from_proto() and FeatureViewProjection.from_definition()#4030
#4116
Copy link
Labels
kind/bugpriority/p2

Description

@job-almekinders
job-almekinders
opened on Mar 22, 2024
Issue body actions

Context

If a FeatureService object is created and is being passed to both the apply() and the get_online_features() method, the following user warning is thrown:

UserWarning: The FeatureService object that has been passed in as an argument is inconsistent with the version from the registry. Potentially a newer version of the FeatureService has been applied to the registry.

This is caused by a bug in the creation/retrieval of feature_view_projections, which is an attribute of FeatureService. An empty string is set to the name_alias value of FeatureViewProjection when calling from_proto. However, when creating the FeatureViewProjection by creating a FeatureService object (using the default value) name_alias is set to None, because it is created with FeatureViewProjection.from_definition().

The warning is raised here, because the feature_service_from_registry has the empty string value for the underlying FeatureViewProjection.name_alias object, while the for _features the underlying FeatureViewProjection.name_alias is valued None.

Expected Behavior

I would expect that if a FeatureViewProjection encapsulated within a FeatureService has a None value for the name_alias attribute when being stored in the feature store, that it would also load with the same None value when calling FeatureViewProjection.from_proto().

Then the comparison should also not fail, and the warning should not be thrown.

Current Behavior

The FeatureViewProjection is loaded with an empty string for the value name_alias when FeatureViewProjection.from_proto() is called.

This causes the. comparison to fail, and the warning to be thrown.

Steps to reproduce

docker-compose.yml

---
version: "3"
services:
  db:
    restart: always
    image: postgres:16-alpine
    container_name: feast_db
    ports:
      - "5432:5432"
    environment:
      - POSTGRES_DB=feature_store
      - POSTGRES_USER=postgres
      - POSTGRES_PASSWORD=test

feature_store.yaml

project: project_name
provider: local
registry:
    registry_type: sql
    path: postgresql://postgres:[email protected]:5432/feature_store

Python script

from datetime import timedelta

import pandas as pd
from feast import (
    Entity,
    FeatureService,
    FeatureStore,
    FeatureView,
    Field,
    SnowflakeSource,
    ValueType,
)
from feast.types import Float32

feature_store = FeatureStore()

# Apply
entity = Entity(
    name="entity",
    join_keys=["ID"],
    value_type=ValueType.STRING,
)

source = SnowflakeSource(
    name="source_snowflake",
    timestamp_field="EVENT_TIMESTAMP",
    schema="TEMP",
    table="FEAST_FEATURES",
)

feature_view = FeatureView(
    name="feature_view__v1",
    entities=[entity],
    ttl=timedelta(days=0),
    schema=[
        Field(name="FEATURE", dtype=Float32),
    ],
    online=True,
    source=source,
)

feature_service = FeatureService(
    name="feature_service__v1",
    features=[feature_view],
)

feature_store.apply(
    [
        entity,
        source,
        feature_view,
        feature_service,
    ]
)

# Inference
entity_rows = [{"ID": "ID1"}, {"ID": "ID2"}]
entity_df = pd.DataFrame(entity_rows)
entity_df["event_timestamp"] = pd.to_datetime("now", utc=True)

online_features = feature_store.get_online_features(
    entity_rows=entity_rows,
    features=feature_service,
).to_dict()

print(online_features)

Specifications

Using postgres registry.

  • Version: 0.36.0
  • Platform: MacOS - M1
  • Subsystem: Sonoma 14.1.1

Possible Solution

I have little to no experience with proto, so I'm not sure whether it would be possible to load the None value directly from the proto definition.

One potential solution would be to check whether an empty string is loaded for this field when loading from proto, and then set it to None in the from_proto function.

Activity

  1. job-almekinders
    added
    kind/bug
    priority/p2
    on Mar 22, 2024
  2. job-almekinders
    changed the title [-]Bug: UserWarning when passing `FeatureService` object to both `apply()` and `get_online_features() - Caused by difference in `FeatureViewProjection.from_proto()` and `FeatureViewProjection.from_definition()`[/-] [+]Bug: UserWarning when passing `FeatureService` object to both `apply()` and `get_online_features()` - Caused by difference in `FeatureViewProjection.from_proto()` and `FeatureViewProjection.from_definition()`[/+] on Mar 22, 2024
  3. tokoko commented on Mar 22, 2024

    @tokoko
    tokoko
    on Mar 22, 2024
    Collaborator
    More actions

    Tracked down the PR from where the mysterious or "" originates #2321 Still no idea why that was added, though. Normally, round-trip to and from proto should not change the object (at least as far as == operator is concerned), so it does look like a bug.

  4. job-almekinders commented on Mar 25, 2024

    @job-almekinders
    job-almekinders
    on Mar 25, 2024
    ContributorAuthor
    More actions

    Thanks for your reply.

    I'll try to open a PR for this :)

    Reacted by Tornike Gurgenidze
  5. job-almekinders commented on Mar 25, 2024

    @job-almekinders
    job-almekinders
    on Mar 25, 2024
    ContributorAuthor
    More actions

    I see there might be some changes required for the proto definition as well. I'm however not very familiar with this, and I'm unfortunately not able to look into this right now.. If someone else has the knowledge and time to pick this up soon that would be highly appreciated 🙏

  6. tokoko commented on Mar 25, 2024

    @tokoko
    tokoko
    on Mar 25, 2024
    Collaborator
    More actions

    @job-almekinders my initial though was that simply removing or "" from to_proto method would be sufficient, but I may be wrong... I'll take a stab at it later if no one picks it up

    Reacted by Job Almekinders
  7. franciscojavierarceo
    closed this as completedin #4116on Apr 19, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    kind/bugpriority/p2

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions

      You are visitor 01402503 — GeezerVison does not store the pages you look up.
      Best viewed with Netscape Navigator 4.7 or Internet Explorer 6 at 800×600. No cookies required.