EVO-72 driver: approval emails are not coalesced against burst grading (median 55min for 8 emails) - decide the coalescing policy
MEASURED DRIVER of the EVO-72 'horrible weekly emails' / over-4-emails complaint, found while investigating MARS-525. Rectificar is NOT the driver (154 sends in 60 days vs 1958 for practica-aprobada, and the weekly rectificar cron has never run) - per-approval notifications are, and specifically their ABSENCE OF COALESCING against burst grading. Measurement (live prod, 60 days, 2026-09-11): over 659 student-weeks containing at least one review, 191 (29%) carried >=4 review emails and 137 (20.8%) carried >=5; peak 20 in one week for one student. For the 137 heavy weeks: mean 8.3 emails, MEDIAN first-to-last review span 55 MINUTES, 70/137 fit entirely inside one hour, 105/137 came from a SINGLE reviewer. p90 span is 96h so there is a second slower mode too. Instrument: one practicaReviews row = one student email, validated at 2130 reviews vs 2125 email-sent events (0.2% gap). So the shape is one teacher grading a student's whole backlog in a single sitting, and the app emailing per row. Every one of those sends is individually correct and individually wanted - nothing in the system knows how many emails a recipient already got this week, because there is no cross-family per-recipient rate limit anywhere on the send path. DECISION NEEDED FROM ELAZAR BEFORE ANY BUILD, since this is product feel, not a bug: should a grading session coalesce into one student email (per-student digest with a short delay / same-session rollup), or is per-practica immediacy worth the burst? Do NOT implement a fix off this row without that answer. Bound: figures cover the per-review family only. appEvents email-sent carries no recipient address, so total per-student inbox volume across all families is not computable from the log - the teacher-comment->student family (98/60d) also lands in student inboxes and is not in the distribution above. Full method + coverage statement: mars/pm/reports/2026-09-11-mars525-rectificar-email-workflow.md
Activity
-
parent=#2199
-
BURST DATUM for the coalescing policy this row has to decide, measured 2026-10-05 rather than modelled. ONE reviewer produced a sustained email stream from 09:53:05Z to 11:52:59Z - about 50 sends in two hours, cadence roughly one per 40-60 seconds, every row attemptCount 1, recipientCount 1, blockedRecipientCount 0. Mixed classes in the same stream, not just approvals: "Práctica aprobada", "Práctica para rectificar" and "Nuevo comentario en tu práctica" all interleaved, which matters because a coalescing window keyed only on the approval class would leave the comment notices uncoalesced and still produce a per-action stream. The median-55-minutes-for-8-emails figure in this row title is a different and gentler shape than what happened today; today is the dense end and is the better calibration case. NOT AN ARGUMENT FOR A WINDOW YET: each email here goes to a DIFFERENT student, so per-recipient coalescing would have merged almost nothing. The burst is a load fact about the DB and the mailer, and it is only a notification-volume problem for whichever students received several in one sitting - that per-recipient distribution is the number this row actually needs and I have not computed it.