mirror of
https://github.com/R0m1k3/LogiFlow.git
synced 2026-10-11 17:27:31 +02:00
MichaelandClaude Fable 5
753b301066
The app degraded progressively over a year of data growth. Four causes, all cumulative: 1. No indexes. Apart from primary keys, unique constraints and session.expire, no table carried an index. PostgreSQL does not index foreign keys automatically, so every filter and join on group_id, supplier_id, order_id and the date columns did a sequential scan. Worst offender: user_groups.user_id, read by getUserWithGroups() on every authenticated request. 2. N+1 in the order and delivery listings. getOrders, getOrdersByDateRange, getDeliveries and getDeliveriesByDateRange issued one to two queries per row to load relations. Relations are now loaded in bulk and grouped in Node: three queries regardless of volume. 3. /api/sync-order-delivery-status reloaded the whole deliveries table on every iteration of its loop over orders. It now uses the deliveries getOrders() already attaches. 4. clearExpiredCache() was implemented but never called, so invoice_verification_cache grew without bound. Now scheduled every 6h. Also replaces the full-history downloads on the Groups and Suppliers pages, which fetched every order and delivery with nested relations only to count rows, with aggregate endpoints that count in the database. Indexes are created via scripts/auto-migrate-production.sh, the script that actually runs at deploy time, using CREATE INDEX CONCURRENTLY so no write lock is taken. Note that server/migrations.ts explicitly ignores the migrations/ directory and runs only hardcoded migrations; the SQL file added there is for reference and manual application. Verified: typecheck baseline 440 errors, 430 after, none new in the changed code; vite build passes; server boots; functional test confirms the aggregate endpoints match the source data including the delivered count. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>