René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"Feast SQL registry fails to start due to truncated FeatureView protobuf in MySQL (BLOB size limit)","articleBody":"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](https://feastopensource.slack.com/archives/C01M2GYP0UC/p1767026747833689).\n\nI think this is related with issue https://github.com/feast-dev/feast/issues/3703\n\n Here you have the details.\n\n## Expected Behavior\n\nFeast 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.\n\n## Current Behavior\n\nFeast 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).\n\nWith 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:\n\n```txt\ngoogle.protobuf.message.DecodeError:\nError parsing message with type 'feast.core.FeatureView'\n```\n\nAt this point:\n- feast `serve` fails.\n- any Feast CLI command that loads the registry fails.\n- recovery requires manual MySQL registry intervention: Which is deleting the featureview row in the `feature_views` table.\n- No matter the FeatureView definition itself is small; growth comes from accumulated materialization interval history.\n\n## Steps to reproduce\n\n1. 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.\n2. Define a FeatureView and run `feast apply`.\n3. Run `materialize-incremental` repeatedly over time (e.g. via a cron job).\n4. Observe that the registry entry for the FeatureView grows on each run (~30 bytes). For that you can use the following query:\n\n```sql\nSELECT\n  feature_view_name,\n  project_id,\n  OCTET_LENGTH(feature_view_proto) AS proto_bytes\nFROM feature_views;\n```\n\nTo get an output like:\n\n| feature_view_name | project_id | proto_bytes |\n| ------ | ------ | ------ |\n|    my_test_fv    |    my_test_project    |   65535     |\n\n5. Once the stored proto reaches 65,535 bytes (like in the example), MySQL truncates it.\n6.  Run `feast serve`, it will fail to load with protobuf `DecodeError`.\n\n### Specifications\n\n- Version: `v0.58.0`\n- Platform: docker. \n- Subsystem: both arm and amd images.\n\n## Possible Solution\n\nClarify and/or improve SQL registry behavior for long-running deployments, for example by:\n\n- SQL registry `BLOLB` columns must be unbounded (`MEDIUMBLOB` / `LONGBLOB`), but this is just a temporal solution.\n- Introducing pruning of materialization interval history.\n\nPlease tell me if you need more information. Thanks in advance!","author":{"url":"https://github.com/PepeluDev","@type":"Person","name":"PepeluDev"},"datePublished":"2025-12-30T11:37:09.000Z","interactionStatistic":{"@type":"InteractionCounter","interactionType":"https://schema.org/CommentAction","userInteractionCount":0},"url":"https://github.com/5800/feast/issues/5800"}