Ticket: HEL-700
Date: 2026-04-10
Two issues survive the HEL-699 deploy:
The HEL-699 decodeURIComponent fix was deployed in server.cjs, but server.cjs is loaded once at container startup (exec node /app/docker/server.cjs). git pull updates the file on disk, but the running Node.js process never reloads it. The fix only takes effect after the container is restarted.
The user's deploy triggered the zero-downtime git pull path — page/SQL changes took effect instantly (that's why the Dropdown and timestamps are visible). But server.cjs is an infrastructure file; it needs a Coolify rebuild + container restart to actually run the new code.
The evidence-service container is therefore still running the old server.cjs that looks up %20-encoded paths, which don't exist on disk.
Rather than rely on a container restart, fix it in nginx: rewrite the %20 URL to a literal space before proxying. The backend then receives /Service Delivery/... and the existing path.join works without needing decodeURIComponent.
In docker/nginx.conf, replace:
location ~ "^/Service%20Delivery/" { proxy_pass http://evidence-service; }
location ~ "^/College%20Outcomes/" { proxy_pass http://evidence-outcomes; }
With:
location ~ "^/Service%20Delivery/" {
rewrite "^/Service%20Delivery/(.*)" "/Service Delivery/$1" break;
proxy_pass http://evidence-service;
}
location ~ "^/College%20Outcomes/" {
rewrite "^/College%20Outcomes/(.*)" "/College Outcomes/$1" break;
proxy_pass http://evidence-outcomes;
}
This requires a Coolify rebuild of only the nginx container (quick — just FROM nginx:alpine; COPY nginx.conf). The decodeURIComponent fix in server.cjs stays as an additional safety net for future cases.
The code fix is correct — Dropdown + .value accessor matches the working b5c8493 pattern. The grey flash is not a reactivity bug; it resolves eventually but takes too long.
The bottleneck: sources/postgres_heroku/order_products.sql has no date filter — it pulls every order product ever created. Two CTEs in every month-switching query join against this full table:
order_totals: orders (2025+) × order_products (all time)expected_first_payment: same joinWhen DuckDB WASM downloads and scans the full order_products parquet on every month change, it's slow. The other large tables (order_payments, orders, payment_informations, student_orders) all have WHERE created_at >= '2025-01-01' filters; order_products has none.
order_products.sql-- Before
SELECT *
FROM order_products;
-- After
SELECT op.*
FROM order_products op
INNER JOIN orders o ON o.id = op.order_id
WHERE o.created_at >= '2024-01-01'
ORDER BY op.order_id
Using 2024-01-01 (one year before the other 2025 cutoffs) as a safe margin in case any current-student orders were placed in late 2024. This runs in PostgreSQL during npm run sources, not in the browser, so the JOIN cost is server-side and one-time.
This is the same pattern used to fix comments.parquet (HEL-684) — remove data the browser never needs.
docker/nginx.conf — add rewrite directives for Service%20Delivery and College%20Outcomessources/postgres_heroku/order_products.sql — add date filter via JOIN with orders/Service%20Delivery/contact_health returns 200 in production/College%20Outcomes/ returns 200 in productionorder_products.parquet is significantly smaller after rebuildnpm run build:strict passes clean