* feat: implementing registry lineage for PushSource

Signed-off-by: Mao Liu <[email protected]>

* rename source_views to upstream_feature_view_names, add docs and validation

Signed-off-by: Mao Liu <[email protected]>

---------

Signed-off-by: Mao Liu <[email protected]>

Register the LanceDataset with DuckDB instead of materializing it with
to_arrow(), so the query's column projection is pushed into the Lance
scanner. Retrievals that select scalar features no longer read the
embedding columns stored next to them.

Signed-off-by: haoxu0 <[email protected]>

)

* fix: Keep the metrics server running when a Gunicorn worker exits

Since the metrics server runs in a multiprocessing.Process started in
the Gunicorn master, every forked worker inherits multiprocessing's
registry of child processes. At worker exit,
multiprocessing.util._exit_function terminates every daemon process in
that registry, so the first worker restart (--max-requests, timeout,
reload) sends SIGTERM to the master's metrics server and /metrics stops
responding. It also logs "AssertionError: can only join a child
process" on every worker exit.

Register an at-fork hook when the metrics process is started that
removes it from the registry in every forked child. Workers no longer
terminate it; the master still does on its own exit.

Fixes #7011

Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>
Signed-off-by: Alexandr Borgatin <[email protected]>

* test: Wait for the metrics server before forking in the worker-exit test

On macOS CI the spawned metrics process can take longer than the 5 s
readiness wait to start listening, so the first /metrics request was
refused. Poll /metrics (up to 30 s) before forking the child.

Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>
Signed-off-by: Alexandr Borgatin <[email protected]>

* test: Use an instant stand-in process in the worker-exit test

The spawned metrics server did not come up within 30 s inside the full
unit suite on macOS CI. The test is about the process surviving a
forked child's exit, not about serving HTTP, so register a fork-context
daemon process via start_metrics_server instead and assert it is still
alive after the child runs multiprocessing.util._exit_function().
Without the fix it is terminated (exitcode -SIGTERM).

Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>
Signed-off-by: Alexandr Borgatin <[email protected]>

* test: Check active_children() in the forked child instead of running _exit_function

Running multiprocessing.util._exit_function() in a fork of the pytest
process runs every registered finalizer. Check what a worker's exit
would act on instead: the metrics process must not be in the child's
active_children(). Also cover _forget_metrics_process_in_child directly,
and kill the stand-in process in cleanup (terminate() can wait out the
join timeout under xdist).

Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>
Signed-off-by: Alexandr Borgatin <[email protected]>

---------

Signed-off-by: Alexandr Borgatin <[email protected]>
Co-authored-by: Claude Opus 5.5 (1M context) <[email protected]>

* fix: Fail Ray materialization when the online store write fails

When the online store refused a write, the Ray engine only logged the
error and still reported the job as SUCCEEDED. Users kept getting old
feature values and had no sign that anything went wrong.

Now the error is raised again after it is logged, and the write step is
no longer wrapped in safe_batch_processor, which hid every error. A
failed write now fails the job, the same as with the Local engine.

Fixes #7024

Signed-off-by: Chaitany Patel <[email protected]>

* fix: Keep timestamps when Ray aggregates a BatchFeatureView

The Ray aggregation step kept only the entity keys and the aggregated
values. It dropped the event timestamp and created timestamp columns.
The online store write needs these columns, so writing an aggregated
BatchFeatureView to the online store always failed. The previous commit
made this failure visible.

Now the aggregation keeps the latest event timestamp and created
timestamp for each entity.

Signed-off-by: Chaitany Patel <[email protected]>

* fix: Run the Ray UDF before aggregation in historical retrieval

In materialization, the Ray engine ran the UDF on raw rows before
aggregation. In historical retrieval, it ran the UDF after aggregation.
So a UDF could only work in one of the two paths. In the other path it
raised an error, and safe_batch_processor hid that error, so users got
values that were never transformed.

Now historical retrieval also runs the UDF on raw rows before
aggregation. This matches the compute engine docs and the Local and
Spark engines. The transformation step is no longer wrapped in
safe_batch_processor, so a UDF error now fails the job.

A UDF that used aggregated column names (for example sum_conv_rate)
must now use the raw column names (for example conv_rate).

Signed-off-by: Chaitany Patel <[email protected]>

---------

Signed-off-by: Chaitany Patel <[email protected]>

#7037)

The go-feature-server image was built and shipped from the full
golang:1.26 image, so every published tag carried the Go toolchain,
gcc, protoc, the module and build caches, and Debian development
packages such as linux-libc-dev. Those packages are flagged by
container scanners (for example DSA-6238-1, DSA-6253-1, DSA-6274-1 and
DSA-6295-1 against linux-libc-dev), and users cannot remediate them
because they come from the base layer.

Keep the existing build steps in a builder stage and copy only the
compiled binary into a debian:trixie-slim runtime stage with
ca-certificates. The builder is pinned to golang:1.26-trixie, which is
what golang:1.26 resolves to today, so the cgo-linked binary (needed by
go-sqlite3) runs against the same glibc release. The working directory,
binary path, exposed port and default command are unchanged, so
existing deployments that mount a feature repo under /app or pass
--chdir keep working.

The runtime image no longer contains linux-libc-dev, the Go toolchain
or compilers, and drops from about 3.1 GB to about 214 MB.

Fixes #7060

Signed-off-by: NopeCharon <[email protected]>

Signed-off-by: sarankumar1325 <[email protected]>