Audit and prune CELERYBEAT_SCHEDULE — drop post-campaign no-op jobs

[rdhyee]

Problem

regluit/settings/prod.py (rendered from prod.py.j2) registers 11 scheduled jobs under the if 'prod' == 'prod': branch. Most of these date from the active-campaign era (pre-April 2024) and are likely no-ops or near-no-ops in 2026, but they continue to fire on schedule against a production DB and broker.

Inventory (from prod's rendered prod.py):

Job key	Task constant	Likely 2026 status
update_active_campaign_statuses	UPDATE_ACTIVE_CAMPAIGN_STATUSES	Likely no-op — campaigns ended April 2024
report_new_ebooks	EBOOK_NOTIFICATIONS_JOB	Probably still relevant — DOAB-driven
notify_ending_soon	NOTIFY_ENDING_SOON_JOB	Likely no-op — nothing ending
update_account_statuses	UPDATE_ACCOUNT_STATUSES	Likely no-op — pledger accounts dormant
notify_expiring_accounts	NOTIFY_EXPIRING_ACCOUNTS	Likely no-op
refresh_acqs	REFRESH_ACQS_JOB	Overwritten in same dict by NOTIFY_UNCLAIMED_GIFTS (bug?)
refresh_acqs	NOTIFY_UNCLAIMED_GIFTS	Likely no-op — no active gifts
save_info_page	SAVE_INFO_PAGE	Generates daily metrics-YYYY-MM-DD.html — still firing
periodic_cleanup	PERIODIC_CLEANUP	Active — runs clearsessions + cleanupregistration
emit_notices	EMIT_NOTICES	Active — user notification queue
feature_new_work	FEATURE_NEW_WORK	Rotates featured work; may or may not still matter UX-wise

Bonus bug: refresh_acqs is declared twice in the schedule dict — second declaration silently overwrites the first. Either intentional (one is dead code) or a paste error from years ago.

Why audit this

• Each scheduled job that no longer does anything is wasted broker traffic and DB load — small per-job, but accumulates
• The schedule is a maintenance hazard: dead constants like SEND_TEST_EMAIL_JOB lurked in this file for years before triggering security-private#13. Pruning what's dead reduces the surface area for the next "rogue email" class of incident.
• A small, reviewed, well-named schedule is a forcing function for honest documentation of what prod actually does on a cadence

Proposed approach

1. Read each task in regluit/core/tasks.py and trace what it does today
2. Categorize as: keep / prune / rewrite-into-cron-job
   • Cron candidates: anything that's better expressed as manage.py <command> on a cadence (cf. periodic_cleanup calling clearsessions + cleanupregistration)
3. Single PR removing the dead entries from prod.py.j2 + their constants from common.py + their task functions if no other caller
4. Validate by re-running through the falsification check (Received task lines for surviving jobs only) post-deploy

Coordinate with

• Automate DOAB harvesting on same cadence as doab-check #1129 — DOAB harvester automation. If report_new_ebooks survives the audit and we move it to cron, that's the same conversation.
• Remove Django comments functionality — spam magnet, Eric approved removal #1130 — Django comments removal. Comments aren't on the schedule but Eric called them spam-magnet code; same energy.
• The new "fix beat observability" issue (sibling follow-up to celerybeat on prod runs but doesn't fire scheduled jobs (silent for 6+ days, possibly years) #1138) — should land first, so we can verify the audit's effects via beat.log directly.

Decision-needed-before-coding

Eric should confirm which of the "likely no-op" jobs actually have user-visible value in post-campaign mode. Some may still be reachable from admin tools or rare edge cases (e.g., a pledger logging in after years could trigger update_account_statuses semantics). Don't prune blind.

Related

• celerybeat on prod runs but doesn't fire scheduled jobs (silent for 6+ days, possibly years) #1138 (closed) — discovery context
• Remove dead "HiThere" test-email task (SEND_TEST_EMAIL_JOB) #1131 (closed) — same prod.py.j2 template; the boolean-group_vars cleanup proposal applies here too