fix: Allow serving features while a feature view is MATERIALIZING - #6789
fix: Allow serving features while a feature view is MATERIALIZING#6789alan-gauthier-jt wants to merge 3 commits into
Conversation
|
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## master #6789 +/- ##
=======================================
Coverage 47.08% 47.08%
=======================================
Files 419 419
Lines 51877 51876 -1
Branches 7525 7524 -1
=======================================
Hits 24428 24428
Misses 25700 25700
+ Partials 1749 1748 -1
*This pull request uses carry forward flags. Click here to find out more.
Continue to review full report in Codecov by Harness.
🚀 New features to boost your workflow:
|
f9755ad to
9ae554a
Compare
jyejare
left a comment
jyejare
left a comment
There was a problem hiding this comment.
This PR introduces a new configuration option 'serve_features_while_materializing' to allow feature serving to continue during materialization, preventing serving interruptions. The implementation is well-documented and tested, with proper configuration propagation across registry implementations and clear behavioral boundaries for different feature view states.
| serve_features_while_materializing: StrictBool = False | ||
| """ bool: Allow online serving to continue for a feature view while it is in | ||
| the ``MATERIALIZING`` state. When ``feature_store.materialize()`` runs against | ||
| a shared registry it transitions the feature view to ``MATERIALIZING`` and | ||
| commits that state, which otherwise causes concurrent feature servers to | ||
| reject requests until materialization completes. When True, feature views in | ||
| the ``MATERIALIZING`` state keep serving their last-materialized values. | ||
| Truly-unavailable states (e.g. ``CREATED``, ``GENERATED``) remain gated. """ |
There was a problem hiding this comment.
[Suggestion] Consider adding validation for incompatible configurations
While the documentation is clear, consider adding runtime validation to ensure this setting doesn't conflict with other registry configurations that might make serving during materialization unsafe.
The lifecycle serving gate added in v0.64.0 rejects any feature view not in AVAILABLE_ONLINE / STATE_UNSPECIFIED state. Because materialization transitions a feature view to MATERIALIZING in the shared registry, routine incremental materialization interrupts concurrent feature servers with "cannot serve features. Only AVAILABLE_ONLINE feature views can serve." Add an opt-in registry config flag, serve_features_while_materializing (default False), that also permits serving while a feature view is MATERIALIZING, letting servers keep returning last-materialized values during materialization. States that never had online data (CREATED, GENERATED) remain gated. Fixes feast-dev#6780 Signed-off-by: Alan Gauthier <alan.gauthier@jobteaser.com>
test_module_level_fips_sets_env_before_pyarrow_import spawns a cold subprocess that imports feast.offline_server, pulling in pyarrow and gRPC. On contended CI runners (observed on macOS) this can exceed the 60s timeout and fail with subprocess.TimeoutExpired, even though the import itself is healthy (~3-7s locally). Raise the timeout to 300s to give ample headroom against runner contention while still catching a genuine import hang. Signed-off-by: Alan Gauthier <alan.gauthier@jobteaser.com>
Emit advisory (non-fatal) warnings when the flag is combined with a non-sql registry (no-op) or cache_mode='thread' (state transitions may be observed stale). Signed-off-by: Alan Gauthier <alan.gauthier@jobteaser.com>
2135fce to
a8e32e3
Compare
3 participants
What this does
Adds an opt-in registry config flag,
serve_features_while_materializing(defaultfalse), that lets online serving continue for a feature view while it is in theMATERIALIZINGstate.Problem
The lifecycle serving gate introduced in v0.64.0 (#6401) rejects any feature view whose state is not
AVAILABLE_ONLINEorSTATE_UNSPECIFIED:FeatureStore.materialize()transitions a feature view toMATERIALIZINGand commits that state to the registry. In the standard pattern — one shared registry, periodic incremental materialization, and a separatefeast serveprocess — this means routine materialization interrupts online serving until it completes.Fixes #6780.
Change
When
serve_features_while_materializing: trueis set underregistry:,MATERIALIZINGis added to the set of servable states, so servers keep returning the last-materialized values during materialization. States that never had online data (CREATED,GENERATED) remain gated, and the default (false) preserves current behavior.The flag follows the existing plumbing pattern of
enable_online_feature_view_versioning: aRegistryConfigfield, copied onto the registry object in__init__(protoRegistryandSqlRegistry), and read viagetattr(registry, ...)in the gate.Testing
test_feature_view_state.pycovering:MATERIALIZINGblocked by default, served when the flag is on,AVAILABLE_ONLINEserved regardless, andCREATEDstill blocked even with the flag on.ruff check/ruff formatclean;mypyclean; fulltest_feature_view_state.pysuite passes (33/33).Notes