D8 Tier-2: compute-in-Node over DB rows (cron practicas-kpi-report:277/330/146/208, legacy-export-actions:68-88, hierarchy-utils:22-74/team-stats) -> SQL GROUP BY/ORDER BY

Sub-tickets

Activity

• wi-cli-venus created · 2026-06-14
  parent=#98
• wi-cli-venus assigned · 7w ago
  coder-pluto-cc
• wi-cli-venus completed · 7w ago
  NO-ACTION on measurement — closing without a code change, and the numbers are the reason. PLUTO-99 flagged 4 compute-in-Node-over-DB-rows sites as D8 Tier-2. I assessed 3 of them as style-not-defect on source: the shape is 'fetch rows, reduce in JS' but the row sets are structurally bounded, so moving the GROUP BY into SQL buys correctness nothing and readability little. The 4th (the triage queries feeding a count plus a top-10) was the one that could flip, because it is unbounded by construction — nothing in the query caps it, so its cost is whatever the table holds. MEASURED against live prod by db-pluto-cc (db-pluto-cc-mt48yb0yb1i0, 2026-08-22), single periodo — only one exists: - open supportTickets (status NOT IN Cerrado/Resuelto, not deleted): 1 - open accessRequests (Pendiente/Requiere informacion): 0 - academicHierarchy rows for the periodo: 8 - legacy-export fn_getLegacyPracticaStats(periodoId): 284 Nothing here justifies a restructure. The unbounded triage site returns 1 and 0 rows; the largest number anywhere is the 284-row legacy export, which is an EXPORT — it wants every row by definition, so 'move the aggregation into SQL' does not apply to it. A count+top-N rewrite of a 1-row result is churn on the live query path for no measurable gain, and this is the export/report surface, not a hot path. VERDICT AS A COVERAGE STATEMENT, because the counts do not generalise: what is established is that at CURRENT prod volume, with ONE periodo of real post-cutover data, none of the four sites moves enough rows for compute placement to matter. What is NOT established is behaviour at scale. These are per-periodo counts and pluto accumulates a periodo per academic year; the triage tables in particular are unbounded in the query, so today's 1 is a fact about adoption, not about the code. See pluto-shipped-flow-with-zero-prod-rows — a small count is not proof of a sound shape. RE-OPEN TRIGGER, so the next reader has a threshold instead of a judgement call: revisit if open supportTickets or accessRequests passes ~500 rows, or if the legacy export passes ~5000. Below that the Node-side reduce is not worth a live-path change. Parent PLUTO-98 (D8 remediation self-scan) stays open on its own terms; this closes only the Tier-2 leg.