…st-dev#6704)

* fix: Fix mypy TorchTensor type alias error

Fix the TypeAlias annotation of TorchTensor in the fallback branch of online_response.py to stop mypy from treating it as a variable and raising 'not valid as a type'.

Fixes feast-dev#5563

Signed-off-by: Nithin <kumbam.nithingoud@gmail.com>

* fix: remove redundant `import torch` under TYPE_CHECKING block

The bare `import torch` statement inside the `if TYPE_CHECKING:` branch
was superseded by `from torch import Tensor as TorchTensor` on the
following line. Since `TorchTensor` is the only torch symbol referenced
in type annotations, the standalone module import is unnecessary and
can be dropped without affecting runtime or static-analysis behaviour.

Addresses nitpick raised in code review.

Signed-off-by: Nithin <kumbam.nithingoud@gmail.com>

---------

Signed-off-by: Nithin <kumbam.nithingoud@gmail.com>

* docs: add SparkApplication compute engine guide
Document spark_application batch materialization, operator ConfigMap wiring, and config reference.

Signed-off-by: Aniket Paluskar <apaluska@redhat.com>

* docs: add SparkApplication section to operator batch engine guide
Additive only; leave existing spark ConfigMap example unchanged.

Signed-off-by: Aniket Paluskar <apaluska@redhat.com>

---------

Signed-off-by: Aniket Paluskar <apaluska@redhat.com>

Signed-off-by: ntkathole <nikhilkathole2683@gmail.com>

…oject

Signed-off-by: ntkathole <nikhilkathole2683@gmail.com>

…cess

`SparkApplicationComputeEngine.materialize()` deletes the SparkApplication CR
in its `finally` immediately after `_build_per_fv_jobs()` returns. For a single
feature view, `_build_per_fv_jobs()` short-circuited and returned the live
polling job. `FeatureStore._submit_and_process_materialization_jobs()` then
re-checks `job.status()`, which re-queries the just-deleted CR, gets a 404, and
raises `SparkApplication feast-sa-<id> not found` — for a materialization that
actually succeeded and already updated the registry. Automation calling
`feast materialize` or `/materialize` sees a failure and may retry completed
work. The bug is deterministic for exactly one feature view.

Resolve the per-FV outcome from registry state for every task count, exactly as
the multi-FV path already does: a materialized FV (`AVAILABLE_ONLINE`) becomes a
`CompletedMaterializationJob`, which reports SUCCEEDED without any Kubernetes
call and is therefore safe after cleanup. The now-unused `job` parameter is
dropped. Genuine failures still surface as ERROR (the FV is not
`AVAILABLE_ONLINE`), and the Spark driver's error detail is already logged by
`_wait_for_completion`.

Updated the single-task unit test, which previously asserted the buggy
behavior (return the live job, skip the registry), to require resolution from
registry state with no CR query, and added a single-failed-FV case.

Fixes feast-dev#6673

Signed-off-by: adarshsm <adarshmudugal@deborhn.shop>

test_install_kserve_with_feast installed kserve into the interpreter
running the suite, with no isolation and no cleanup, so it mutated the
environment every other test was using.

Feast pins psutil==5.9.0 and kserve requires psutil>=5.9.6, so pip could
not leave the installed version alone: it uninstalled psutil before
reinstalling 5.9.8. The unit suite runs pytest -n 8 against one
environment, so any test importing psutil in that window failed,
including every test that shells out to the CLI, since feast.metrics
imports it at module scope. That is how an unrelated docs PR got a red
unit-test-python job on test_3rd_party_providers with ModuleNotFoundError:
No module named 'psutil'. Being timing-dependent, it read as flake.

kserve also pulled protobuf down to 4.25.x, which left the environment
broken for the next run: the installed grpcio-health-checking ships
protobuf 6.x gencode importing google.protobuf.runtime_version. The first
run passed because collection imports precede the mid-run install; the
second failed at collection.

--dry-run performs the same resolution and still exits non-zero when the
versions cannot be satisfied together, which is what the test guards
against, without installing anything. Verified both directions: a clean
resolution exits 0 and leaves psutil at 5.9.0 with kserve not importable,
and 'pip install --dry-run kserve==0.15.2 psutil==5.9.0' exits 1 with
conflicting dependencies.

Also replaces the conflict assertion, which was inverted - it was only
true when pip reported conflicts without an error, so a loud failure set
it to False. The exit code was already doing the real work; it now
carries pip's output for diagnosis.

The full unit suite now passes twice in a row: 2529 passed, 20 skipped
both times, with psutil and protobuf unchanged after the first.

Closes feast-dev#6732

Signed-off-by: Larry Singleton <166439969+larrysingleton007@users.noreply.github.com>

Signed-off-by: NIKHIL <atnikhil06@gmail.com>

Copy grouped feature lists before passing them to online stores so Redis
timestamp fields do not accumulate in the shared resolution cache.

Signed-off-by: rapportlabs <junwoo@rapportlabs.kr>

)

* feat: Expose the OIDC JWKS tunables through the operator

Follow-up to feast-dev#6683, requested in its review. Add jwksCacheLifespanSeconds
and jwksRequestTimeoutSeconds to OidcAuthz as CR fields rather than OIDC
Secret keys: these are non-secret operational knobs, so they belong with
verifySSL and caCertConfigMap rather than in the Secret bag that carries
IdP-coupled credentials.

Both are optional pointers with a Minimum=1 constraint mirroring the
SDK's validation, and are omitted from the generated feature_store.yaml
when unset so the SDK defaults apply rather than the operator asserting
its own. Regenerates deepcopy, CRD bases, dist/install.yaml, and the API
reference.

Documents that the cache lifespan is not purely a performance setting:
it also bounds how long a key the provider revoked keeps validating
tokens.

Signed-off-by: Larry Singleton <166439969+larrysingleton007@users.noreply.github.com>

* fix: Regenerate the OLM bundle and close review gaps

Code review findings on the JWKS tunables change.

The OLM bundle CRD was not regenerated, so it lacked both new fields
while config/crd/bases and dist/install.yaml carried them. Every other
OidcAuthz field is present in all three copies, and no PR workflow runs
make bundle, so CI would not have caught it: an OLM install would have
pruned the settings silently rather than failing. Regenerated with
make bundle; operator-sdk bundle validate passes.

Assert the client repo config omits both keys. OidcClientAuthConfig
inherits the same strict validation, so mirroring the forwarding into
the client path would break every client pod, and nothing tested it.
Also restore the neighbouring blocks' length assertion so a leaked
parameter fails.

Add CRD validation tests for the Minimum=1 constraints the docs promise.

Docs: caCertConfigMap was documented as a bare string but the CRD
requires an object with a name key, so the whole snippet failed to
apply, including the lines added here. Name the required Feast version
instead of implying any newer image works.

Signed-off-by: Larry Singleton <166439969+larrysingleton007@users.noreply.github.com>

* docs: State that the OIDC authz options require apiVersion v1

The CRD serves v1alpha1 alongside v1 with no conversion webhook, so a
resource submitted as v1alpha1 is validated against the v1alpha1 schema and
any field outside it is pruned without error. Under v1alpha1, authz.oidc
accepts only secretRef, so every other option is silently dropped.

This predates the JWKS settings: v1alpha1 has never carried issuerUrl,
secretKeyName, tokenEnvVar, verifySSL or caCertConfigMap either, all of
which landed v1-only in 7c04026. Documenting the whole section rather
than the two new fields keeps the guidance consistent with that.

The v1alpha1 schema already enforces this - the fields cannot be expressed
there - so no validation change is needed, only the missing warning.

Signed-off-by: Larry Singleton <166439969+larrysingleton007@users.noreply.github.com>

---------

Signed-off-by: Larry Singleton <166439969+larrysingleton007@users.noreply.github.com>

* docs: Correct what _validate_token claims to do

The method is named validate, its docstring says it validates the token
against the OAuth2 server, and the caller logs 'Token successfully
validated' afterwards. None of that holds: the bearer scheme only parses
an Authorization header, and the method builds that header itself, so
every token value passes including the empty string. The token is really
verified in _decode_token.

Anyone auditing the auth path is misled into thinking a verification
step happens here. Describe what the call actually checks (that the
discovery document exposes the OAuth2 endpoints) and log that instead.

No behavior change: docstring and log message only. Whether the call
should exist at all is asked separately in feast-dev#6688.

Signed-off-by: Larry Singleton <166439969+larrysingleton007@users.noreply.github.com>

* refactor: Rename _validate_token to _check_discovery_endpoints

The method never verified the token it takes: it builds a bearer scheme
whose header it supplies itself, so any token value passes. What it does
check is that the discovery document exposes the OAuth2 endpoints, which
is what the docstring already said after the previous commit.

Leaving the old name meant the docstring had to spend its opening
correcting the name. Private method, single caller in the same file, so
the rename is contained.

The access_token parameter stays: the bearer scheme requires a
well-formed Authorization header, and the caller has the token to hand.

Signed-off-by: Larry Singleton <166439969+larrysingleton007@users.noreply.github.com>

---------

Signed-off-by: Larry Singleton <166439969+larrysingleton007@users.noreply.github.com>

feast-dev#6709)

* fix: feast apply ignores ttl updates when new ttl is None or timedelta(0)

Fixes feast-dev#6703. Registry._update_metadata_fields() routes ttl changes on
re-apply through a truthiness check:

    if (... and updated_fv.ttl):

None and timedelta(0) are both the documented way to express "no
ttl", and both are falsy, so re-applying a FeatureView/LabelView with
ttl cleared silently kept the old finite ttl -- feast apply reported
the update but nothing changed in the registry.

Removing that outer truthy gate isn't sufficient by itself: for the
FeatureView branch, get_ttl_duration() returns Python None when
self.ttl is None, and the existing inner check

    if ttl_duration:
        existing_proto.spec.ttl.CopyFrom(ttl_duration)

would still silently skip CopyFrom in that case, leaving the stale
ttl in place. Fixed both by explicitly writing an empty Duration()
(which decodes back to timedelta(0), per FeatureView.from_proto's
existing ToNanoseconds()==0 check) whenever there's no real ttl to
write, instead of skipping the write.

The LabelView branch is adjusted the same way, guarding
FromTimedelta() against a None ttl now that the outer gate no longer
prevents ttl=None from reaching this branch.

Traced all three cases (None, timedelta(0), a finite value) through
the new branch logic in isolation and confirmed FeatureView and
LabelView now resolve identically: None and timedelta(0) both produce
a zero Duration, a finite ttl passes through unchanged.

Signed-off-by: saket3395 <sakettulsan95@gmail.com>

* address review nitpicks: hoist Duration import, guard FromTimedelta

- Move the Duration import to the top of the file with the other
  google.protobuf imports, consistent with how Message and
  RepeatedCompositeFieldContainer are already imported there.
- Wrap FromTimedelta() in the LabelView branch with a try/except,
  re-raising as a ValueError naming the offending value, so an
  invalid timedelta surfaces a clear error instead of a raw
  protobuf exception.

Signed-off-by: saket3395 <sakettulsan95@gmail.com>

* test: cover ttl clearing in _update_metadata_fields (feast-dev#6703)

Adds unit coverage requested in review:
- clearing a finite ttl to None or timedelta(0) now writes a zero
  Duration (previously silently dropped)
- a finite-to-finite ttl update is preserved

_update_metadata_fields uses no instance state, so it is exercised
directly via the class, mirroring the FeatureView/FileSource/Field
construction used elsewhere in the unit tests.

Signed-off-by: saket3395 <sakettulsan95@gmail.com>

* style: apply ruff format to registry.py ttl block

Collapse the multi-line raise ValueError back to a single line per
ruff format (it fits within the 88-char limit), fixing the format
check.

Signed-off-by: saket3395 <sakettulsan95@gmail.com>

---------

Signed-off-by: saket3395 <sakettulsan95@gmail.com>
Co-authored-by: saket3395 <sakettulsan95@gmail.com>

Signed-off-by: Srihari <svenkata@redhat.com>

Signed-off-by: NIKHIL <atnikhil06@gmail.com>

* fix: add remote registry client extra

Signed-off-by: buduoqiu <shenyaodong@hhu.edu.cn>

* chore: update Pixi lock for remote extra

Signed-off-by: buduoqiu <shenyaodong@hhu.edu.cn>

---------

Signed-off-by: buduoqiu <shenyaodong@hhu.edu.cn>

The CI requirements lock files pinned mcp==2.0.0 and mcp-types==2.0.0,
which conflicts with the pyproject.toml constraint mcp>=1.0,<2 added in
a recent change. This caused integration tests and the feature server to
fail with:

  TypeError: Server.__init__() takes 2 positional arguments but 3 were given

This commit:
- Downgrades mcp to 1.29.0 across all nine py3.{10,11,12}-{ci,minimal,minimal-sdist}-requirements.txt lock files.
- Adds httpx-sse==0.4.0 with sha256 hashes to all nine lock files (required by mcp==1.29.0).
- Removes mcp-types from all lock files; mcp==1.29.0 declares no dependency on it.
- Updates unit tests in sdk/python/tests/unit/infra/feature_servers/test_mcp_server.py to isolate RestRegistryServer from unmocked RegistryServer gRPC handlers.

Fixes feast-dev#6706

Signed-off-by: Nithin <kumbam.nithingoud@gmail.com>

Add warmup_connections parameter to DynamoDBOnlineStoreConfig and warm up
connections via describe_limits inside initialize() method to solve cold-start
latency. Also document warmup_connections in the performance tuning guide and
reference docs.

Fixes feast-dev#6060

Signed-off-by: Nithin <kumbam.nithingoud@gmail.com>

Signed-off-by: ntkathole <nikhilkathole2683@gmail.com>

…#6655)

* fix: prefer UDF source over dill; Postgres SELECT *; fresh online registry reads
Rehydrate BatchFeatureView/ODFV callables from body_text (strip leading
decorators) before dill.loads to avoid Spark driver exit 139 and
cross-Python serve failures. Treat empty Postgres feature_name_columns as
SELECT *. Disable registry cache on the online request path so FeatureView
state gates see AVAILABLE_ONLINE immediately after materialize.
RayTransformation.from_proto left unchanged (follow-up).

Signed-off-by: Aniket Paluskar <apaluska@redhat.com>

* Lint

Signed-off-by: Aniket Paluskar <apaluska@redhat.com>

* fix: drop global allow_cache=False on online path

Post-materialize MATERIALIZING gate lag is handled by client retry /
registry TTL refresh, not by bypassing the registry cache on every
online request. Addresses review feedback on feast-dev#6655.

Signed-off-by: Aniket Paluskar <apaluska@redhat.com>
Co-authored-by: Cursor <cursoragent@cursor.com>

* fix: replace UDF decorator strip regex with linear scan

Avoid CodeQL ReDoS finding on nested @/newline regex when rehydrating
body_text. Add multiline and adversarial @ spam unit tests.

Signed-off-by: Aniket Paluskar <apaluska@redhat.com>
Co-authored-by: Cursor <cursoragent@cursor.com>

* fix: cast resolve_udf result to FunctionType for mypy

Signed-off-by: Aniket Paluskar <apaluska@redhat.com>
Co-authored-by: Cursor <cursoragent@cursor.com>

* fix: compare UDF transformations by udf_string when present

Source-first from_proto rebuilds callables whose bytecode differs from
the live repo function; requiring co_code equality made no-op feast apply
rewrite ODFVs and broke universal CLI integration tests.

Signed-off-by: Aniket Paluskar <apaluska@redhat.com>
Co-authored-by: Cursor <cursoragent@cursor.com>

* lint

Signed-off-by: Aniket Paluskar <apaluska@redhat.com>

* fix: align Ray __eq__ with source identity; cache Spark UDF resolve

RayTransformation now compares by udf_string when present (same contract
as Pandas/Python) so a future source-first from_proto will not break
no-op apply. SparkTransformationNode caches resolve_udf so strip+exec
runs once per node lifetime.

Signed-off-by: Aniket Paluskar <apaluska@redhat.com>
Co-authored-by: Cursor <cursoragent@cursor.com>

---------

Signed-off-by: Aniket Paluskar <apaluska@redhat.com>
Co-authored-by: Cursor <cursoragent@cursor.com>