feast ui (0.64.0) renders 0 feature views: packaged web bundle fetches bare registryPath (/api/v1) and 404s instead of calling the REST sub-routes #6601

Expected Behavior

feast ui on 0.64.0 should list projects/feature views/entities from the registry, the same as 0.63.0 and earlier. The registry-server REST API serves them correctly.

Current Behavior

feast ui loads but renders zero feature views / entities. The registry is fine and the REST API returns data — the problem is purely the packaged web UI bundle: it fetches the bare registryPath as a single URL and 404s, instead of calling the REST sub-routes.

feast ui server access log:

GET /projects-list.json  200
GET /api/v1              404 Not Found    <-- the bundle requests the bare registryPath
GET /registry           404 Not Found

projects-list.json correctly advertises the REST base:

{"projects": [{"name": "Mjolner", "id": "mjolner", "registryPath": "/api/v1"}]}

But the REST API works — the data is right there under the sub-routes the bundle never calls:

GET /api/v1            -> 404      (bare base, what the bundle hits)
GET /api/v1/projects   -> 200      {"projects":[{"spec":{"name":"mjolner"},...}],"pagination":{"totalCount":1}}
GET /api/v1/feature_views?project=mjolner -> 200   {"featureViews":[{"spec":{"name":"dam_prc_wrt_pt_v1",...}}, ...]}

So the server side is correct; the prebuilt feast/ui/build/ bundle shipped in the 0.64.0 wheel does not match it. The ui/ source at v0.64.0 is REST-aware (ui/src/queries/useLoadRegistry.ts uses fetchREST() against /projects, /feature_views, …), but the bundled build still treats registryPath as a single endpoint to fetch (pre-REST behavior), which now resolves to /api/v1 and 404s.

When it was introduced

Bisected across releases — this broke in 0.64.0; 0.63.0 and earlier work (they serve the /registry proto dump at registryPath -> /registry, which the bundle consumes):

Introduced in the 0.64.0 cycle by #6414 (REST API-backed UI) together with the removal of the registry proto dump (commit 328431ffe, "Remove registry proto dump to enforce RBAC"). Those moved the server + ui/ source to REST, but the released wheel ships a web bundle that wasn't rebuilt to match.

Backend-independent

feast ui always mounts its own /api/v1 and emits the same projects-list.json / JS bundle regardless of registry_type. registry_type: remote only changes where the UI backend reads data from before re-serving it under /api/v1/*; the stale bundle still fetches bare /api/v1 and 404s. (Reproduced here against a local SQL registry.)

Steps to reproduce

1. Run feast ui on 0.64.0 against any registry that has feature views (reproduces with a local SQL registry; no remote server required).
2. Open the UI — no feature views render.
3. Server access log shows GET /api/v1 404, while GET /api/v1/projects and GET /api/v1/feature_views?project=<p> return 200 with data.

Specifications

• Version: 0.64.0 broken; 0.63.0 and earlier work. Introduced by feat: REST API-backed UI for RBAC compatibility and per-page lazy loading #6414 + 328431ffe.
• Platform: Kubernetes, quay.io/feastdev/feature-server:0.64.0, feast ui
• Subsystem: Web UI / registry REST API packaging

Possible Solution

Rebuild/repackage the feast/ui/build/ bundle shipped in the wheel from the current REST-aware ui/ source (or bump the bundled @feast-dev/feast-ui to a version that consumes the /api/v1/* REST routes), so the packaged UI matches the registry-server it ships with.

Additional context

Happy to provide full request/response captures or test a fix against our setup.