GeezerVison

What this does

Fixes #6673.

Every single-feature-view materialization on the spark_application batch engine is reported as a failure:

Exception: SparkApplication feast-sa-<job-id> not found

even though the Spark driver already materialized the features and updated the registry. Automation calling feast materialize or the feature server's /materialize endpoint sees a failure and may retry work that already succeeded. It is deterministic for exactly one feature view.

Root cause

materialize() deletes the SparkApplication CR in its finally immediately after _build_per_fv_jobs() returns:

try:
    self._wait_for_completion(job)
    return self._build_per_fv_jobs(registry, tasks, job_id, job)
finally:
    self._cleanup(job_id)          # deletes the CR

For a single feature view, _build_per_fv_jobs() short-circuited and returned the live polling job:

if len(tasks) <= 1:
    return [job for _ in tasks]

FeatureStore._submit_and_process_materialization_jobs() then re-checks job.status(). On success the job has no captured error, so status() re-queries the CR that _cleanup() just deleted → 404 → _error set → ERROR raised. (On genuine failure job._error is already set and status() short-circuits, so only the success path 404s.)

Fix

Resolve the per-FV outcome from registry state for every task count — exactly what the multi-FV path already does. The driver pod sets each materialized FV to AVAILABLE_ONLINE, so:

• materialized FV → CompletedMaterializationJob, which reports SUCCEEDED with no Kubernetes call and is safe after cleanup;
• unmaterialized FV → ERROR (was not materialized …), consistent with the existing multi-FV behavior; the Spark driver's error detail is already logged by _wait_for_completion.

The now-unused job parameter to _build_per_fv_jobs() is dropped.

Tests

The existing single-task test asserted the buggy behavior (return the live job, skip the registry). Rewrote it to require resolution from registry state with no CR query, and added a single-failed-FV case. All spark_application unit tests pass; the fix is exercised entirely with mocked K8s/registry — no live cluster needed.

Verified the before/after on the real classes: a live job re-checked after CR deletion returns ERROR "… not found" (the reported symptom), while the fixed single-FV path returns SUCCEEDED and makes no get_namespaced_custom_object call.