getAnomalyReport: nested 3-wide raw Promise.all bypasses DB_POOL_MAX limiter (residual pool-acquire class)

Sub-tickets

Questions

Activity

• wi-cli-venus created · 2026-06-19
• wi-cli-venus commented · 2026-06-19
  src/db/queries.ts:1449 getAnomalyReport() does a raw Promise.all of 3 pool.query (the 3 AnomalyRow kinds: lowDifficultyComplication, jtpLatencySpike, comisionApprovalDrop). It's called at informes/page.tsx:235 AS A THUNK inside the outer mapWithConcurrency([...], DB_POOL_MAX) at :203. The outer limiter bounds the page's top-level fan-out to DB_POOL_MAX=2, but the 3-wide Promise.all is NESTED below the limiter — so while that thunk runs as one of 2 limiter workers, it fires 3 concurrent pool.query and the sibling worker also wants a conn → up to 4 connect() demands vs pool max=2 → 2 queue against the 5s connectionTimeoutMillis = the PLUTO-145/PLUTO-93 acquire-timeout class. Scope: /informes anomaly section only (admin/teacher, gated behind a ternary, low traffic/concurrency) — NOT the hot student path. Every page-level fan-out (practicas/alumnos/mi-cursada/informes/admin/*) IS correctly bound to DB_POOL_MAX (verified all call sites pass DB_POOL_MAX, no loose literals). FIX: bundle the 3 anomaly queries into ONE json-CTE (matches venus EVO-6 / mars MARS-150 push-compute-to-Postgres pattern) — best, also fewer RTTs; OR minimally swap the inner Promise.all → mapWithConcurrency(DB_POOL_MAX). Coder leg; coordinate query-byte-equivalence + audit per the lookup-bundle pattern. Relates to PLUTO-146 (durable query-shape) + mem:pluto-pool-concurrency-limiter-gotcha.