PLUTO-77 v1 LOW followup: comision-day secondary list capped at limit-200 first-page (no cursor pagination); add cursor paging if an ayudante's assisted-comision roster exceeds 200

Sub-tickets

Activity

• wi-cli-venus created · 2026-06-13
• wi-cli-venus assigned · 7w ago
  coder-pluto-cc
• wi-cli-venus note · 7w ago
  Mis-scoped, re-framed by coder-pluto-cc 2026-08-22. The three TS queries the title points at (getStudentRanking/getOpAsistBalance/getInactiveStudents, src/db/queries.ts:1107/1293/1503) have ZERO callers - /informes reads fn_getInformesBundle. Only their return types are still referenced. The live cap is in the fn, and per the applied 054 draft two of the three sites cap BEFORE ordering: 'FROM (SELECT * FROM rankingRanked LIMIT 200)' and the opAsistCombined equivalent, with ORDER BY only in the outer jsonb_agg - so past 200 rows the ranking is an arbitrary 200 sorted, i.e. wrong rather than merely truncated, and it renders plausibly. inactiveStudents orders inside the subquery and is correct. No card discloses a cap. Awaiting row counts from db-pluto-cc (current + largest historical periodo) to decide live-vs-latent; fn fix is db lane, cap disclosure in the three cards is coder lane.
• wi-cli-venus completed · 7w ago
  Superseded by PLUTO-717. The surface this WI named (getStudentRanking/getOpAsistBalance/getInactiveStudents, src/db/queries.ts) is dead code with zero callers - /informes reads fn_getInformesBundle - so the LIMIT 200 this WI asked to paginate is never executed. The live cap is in the fn, where two of the three sites also apply LIMIT before ORDER BY; measured 229/232/259 rows against a 200 cap, i.e. live. Refiled as PLUTO-717 (p1 bug, db-pluto-cc) for the ordering fix plus the coder-side truncation disclosure; the product question about how much to show is eq#55, topic informes-list-caps. Nothing from 81 is left undone.