medium priority low complexity documentation pending documentor Tier 22

Acceptance Criteria

Runbook is a single Markdown document committed to the repository under `docs/operations/cron-reminder-runbook.md`
Runbook includes a section on cron schedule registration: how the schedule is registered in Supabase, the cron expression used, and how to change the schedule
Runbook documents the full `cron_execution_logs` table schema with column names, types, and purpose of each field
Runbook explains the advisory lock mechanism: what lock key is used, what happens when a lock is held, and how to manually release a stuck lock via SQL
Runbook documents alerting thresholds: what consecutive failure count triggers an alert, where the alert is sent, and how to update the alert destination
Runbook provides step-by-step instructions for: (1) manually triggering the cron function, (2) temporarily disabling the cron job for maintenance, (3) re-enabling after maintenance
Runbook includes a troubleshooting section with resolution steps for: missed runs, lock contention (stuck lock), ReminderSchedulerService timeouts, and alert channel delivery failure
Runbook documents the activity registration hook: which table and events trigger it, which activity types qualify as contact, and how to verify it is working correctly

Technical Requirements

frameworks
Markdown
apis
Supabase Dashboard
Supabase SQL Editor
data models
cron_execution_logs
assignments
activities
performance requirements
Runbook must be scannable — use headers, bullet points, and code blocks; avoid dense prose paragraphs
All SQL examples must be copy-pasteable and tested against the actual schema
security requirements
Runbook must NOT include actual API keys, webhook URLs, or service role keys — reference environment variable names only
Include a note warning against running manual trigger commands against the production database without notifying the team

Execution Context

Execution Tier
Tier 22

Tier 22 - 1 tasks

Can start after Tier 21 completes

Implementation Notes

Structure the runbook with these top-level sections: Overview, Architecture Diagram, Cron Schedule Registration, Execution Log Schema, Advisory Lock, Alerting, Manual Operations (trigger/disable/re-enable), Troubleshooting, and Activity Registration Hook. Include a simple ASCII or Mermaid diagram showing the flow: Cron fires → acquire lock → invoke ReminderSchedulerService → log result → release lock → (on failure) increment counter → (at threshold) dispatch alert. For the troubleshooting section, focus on the most likely real-world scenarios based on what was observed during implementation and testing. Keep SQL examples minimal and targeted — one query to check recent logs, one to manually release a stuck lock, one to verify last_contact_date state.

Link to the integration test file as a reference for expected behavior.

Testing Requirements

Documentation review: have at least one team member who was not involved in implementation follow the runbook to manually trigger the cron function and verify the execution log is created correctly. Verify all SQL snippets execute without error against the current database schema. Verify all Supabase Dashboard navigation steps are accurate against the current Supabase UI. No automated tests required for this task — review is the validation mechanism.

Component
Assignment Reminder Cron Trigger
infrastructure medium
Epic Risks (2)
high impact low prob technical

If the daily cron job takes longer than 24 hours to complete (due to a large dataset or a slow query), a second instance will start while the first is still running, causing duplicate reminder dispatch for assignments processed twice.

Mitigation & Contingency

Mitigation: Implement an advisory lock that prevents a second run from starting if the first is still active. Monitor run duration via the execution log table and alert if any run exceeds 30 minutes. The 10,000-assignment load test should verify the run completes in under 5 minutes.

Contingency: If a double-run occurs, the idempotency guard in ReminderDispatchService prevents duplicate notifications from being sent. The execution log identifies the overlap and allows the ops team to investigate the root cause.

high impact medium prob integration

If the activity registration hook that resets last_contact_date is implemented incorrectly or not triggered for all activity types (e.g., proxy registrations, bulk registrations), peer mentors will continue receiving reminders even after logging contact, damaging user trust.

Mitigation & Contingency

Mitigation: Audit all code paths that create activity records (direct registration, proxy registration, bulk registration, coordinator proxy) and ensure each path calls the assignment contact update. Write integration tests for each registration path asserting that last_contact_date is updated.

Contingency: Provide an authenticated admin endpoint that allows manual correction of last_contact_date for a specific assignment, enabling ops to resolve individual cases while the bug is fixed and deployed.