🔴 ComplexFeastType.eq treats all nested collection types with same outer shape as equal regardless of inner element type

All nested collection types that share the same outer collection shape (e.g., Array(Array(String)) vs Array(Array(Int32))) are considered equal by ComplexFeastType.__eq__ because it only compares self.to_value_type() == other.to_value_type(), and both map to ValueType.LIST_LIST. This was confirmed experimentally. The same issue affects __hash__.

This causes Field.__eq__ (sdk/python/feast/field.py:86-95) to consider two fields with different nested inner types as identical, which means schema changes (e.g., changing a field from Array(Array(String)) to Array(Array(Int32))) would not be detected during feast apply. The registry diff logic at sdk/python/feast/diff/registry_diff.py:144 uses object equality to determine if an update occurred, so this bug silently drops schema changes for nested collection types.

(Refers to lines 63-67)

In sdk/python/feast/types.py, the ComplexFeastType.__eq__ method (lines 63-67) compares types solely via to_value_type(). For nested collection types (Array(Array(T)), Array(Set(T)), Set(Array(T)), Set(Set(T))), this loses the inner element type, so Array(Array(String)) == Array(Array(Int32)) returns True.

The fix should override __eq__ and __hash__ on Array and Set classes to also compare the base_type recursively. For example:

In the Array class (around line 158), add:

    def __eq__(self, other):
        if isinstance(other, Array):
            return self.base_type == other.base_type
        return False

    def __hash__(self):
        return hash(("Array", hash(self.base_type)))

Similarly for the Set class (around line 203), add:

    def __eq__(self, other):
        if isinstance(other, Set):
            return self.base_type == other.base_type
        return False

    def __hash__(self):
        return hash(("Set", hash(self.base_type)))

This ensures that Array(Array(String)) != Array(Array(Int32)) while keeping Array(String) == Array(String) working correctly.

Was this helpful? React with 👍 or 👎 to provide feedback.

🟡 JSON deserialization of nested collections fails when first inner element is None

In the from_json_object function, nested collections are detected by checking isinstance(value[0], list) at line 95. If a nested collection's first inner element is None (e.g., [None, [1, 2], [3]] — which is how an empty inner collection round-trips through proto as documented), this check returns False. The value then falls through to isinstance(value[0], (float, int, type(None))) at line 108 (True for None), which tries to process the entire list as a flat numeric array. When it attempts message.double_list_val.val.extend(...) with elements like [1, 2], a TypeError is raised because a list cannot be converted to a double.

This affects the feature server HTTP JSON API transport whenever a nested collection feature has None as its first inner element.

Was this helpful? React with 👍 or 👎 to provide feedback.