Hi Feast maintainers! I have observed what i consider a bug, or at least something to be improved, i also shared this in the slack community channel.

I think this is related with issue #3703

Here you have the details.

Expected Behavior

Feast should be able to run long-lived, periodically materialized FeatureViews using the MySQL registry without the registry growing unbounded or becoming unreadable. The registry should not reach a state where feast serve or any CLI command fails due to accumulated internal state.

Current Behavior

Feast records every materialization interval for a FeatureView in the registry. When using the MySQL registry, each materialize / materialize-incremental run appends a new interval record for each feature view feature_view_proto column , causing the serialized FeatureView registry protobuf to grow monotonically (~30 bytes per materialization in our tests).

With enough materializations, the serialized proto exceeds the MySQL BLOB column size limit (65,535 bytes). When this happens MySQL silently truncates the blob, after which Feast fails to start with:

google.protobuf.message.DecodeError:
Error parsing message with type 'feast.core.FeatureView'

At this point:

• feast serve fails.
• any Feast CLI command that loads the registry fails.
• recovery requires manual MySQL registry intervention: Which is deleting the featureview row in the feature_views table.
• No matter the FeatureView definition itself is small; growth comes from accumulated materialization interval history.

Steps to reproduce

1. Configure Feast with a SQL registry backed by MySQL. It uses the BLOB MySQL type for the feature_view_proto column in the feature_views table.
2. Define a FeatureView and run feast apply.
3. Run materialize-incremental repeatedly over time (e.g. via a cron job).
4. Observe that the registry entry for the FeatureView grows on each run (~30 bytes). For that you can use the following query:

SELECT
  feature_view_name,
  project_id,
  OCTET_LENGTH(feature_view_proto) AS proto_bytes
FROM feature_views;

To get an output like:

5. Once the stored proto reaches 65,535 bytes (like in the example), MySQL truncates it.
6. Run feast serve, it will fail to load with protobuf DecodeError.

Specifications

• Version: v0.58.0
• Platform: docker.
• Subsystem: both arm and amd images.

Possible Solution

Clarify and/or improve SQL registry behavior for long-running deployments, for example by:

• SQL registry BLOLB columns must be unbounded (MEDIUMBLOB / LONGBLOB), but this is just a temporal solution.
• Introducing pruning of materialization interval history.

Please tell me if you need more information. Thanks in advance!