My vote is: -1 (non-binding) Verification results:
- PASS: Checksums and PGP signatures are valid - PASS: LICENSE and NOTICE files are correct - PASS: All files have ASF license headers where appropriate (Apache RAT: 0 unknown licenses) - PASS: Source tarball matches the Git tag - PASS: Docker Compose deploys successfully, but with the functional issues described below Steps 1–4 all pass cleanly. My -1 is for the Docker Compose deployment. I can reproduce the Python UDF operator error already reported in https://github.com/apache/texera/issues/5963. While investigating, I found the root cause and a second instance of the same problem. Root cause: the deployment's nginx.conf has drifted out of sync with frontend/proxy.config.json. Several routes that the frontend relies on are missing from nginx.conf, so those requests fall through to the catch-all route, dashboard-service, and return 404. Confirmed broken in the RC2 Docker images ( docker.io/apache/...:1.2.0-incubating-rc2): 1. GET /pve/pves?cuid=... -> 404 This is the issue reported in #5963. The frontend calls /pve/*, but the backend serves it as /api/pve/* on the runtime coordinator. nginx.conf is missing the /pve -> /api/pve rewrite that exists in proxy.config.json. This happens every time a Python UDF operator is selected. 2. GET /api/access/computing-unit/{list,owner,...}/<id> -> 404 This affects the "Share access" feature for computing units. The endpoint exists on workflow-computing-unit-managing-service:8888 and returns 401 when hit directly. However, nginx.conf has no /api/access/computing-unit route, so the request is routed to dashboard-service and returns 404. Suggested fix: add these blocks to nginx.conf before the location / fallback: location /pve/ { rewrite ^/pve/(.*)$ /api/pve/$1 break; proxy_pass http://workflow-runtime-coordinator-service:8085; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } location /api/access/computing-unit/ { proxy_pass http://workflow-computing-unit-managing-service:8888; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } I verified both fixes live on the RC2 stack: /pve/pves went from 404 to 200, and /api/access/computing-unit/owner/1 went from 404 to reaching the intended service. Since #5963 is not isolated, I suggest auditing nginx.conf against frontend/proxy.config.json for any other missing routes before cutting the next release candidate. Best regards, Kary
