Skip to main content

Part 7 — Scheduling (Cron)

The daily trigger that fires the digest. It runs on Tal's platform-jobs scheduler — which is distinct from the delivery mechanism. Platform-jobs is the "when"; the campaign→SQS→dispatcher pipeline (Part 4) is the "how it's sent".

Mechanism​

  • A platform-jobs handler run_notify_digest_schedules (apps/platform-jobs/src/jobs/handlers/run-notify-digest-schedules.handler.ts), registered in the jobs registry.
  • On fire, it sends RUN_SCHEDULED_DIGESTS to notifications with the schedule's payload.targets ([{ organizationId, communityIds }]); the service runs runDigestNow per target.
  • A job schedule doc: daily CRON at 09:00 in the organization timezone, plus a manual/ONCE trigger for support-tool "Run digest now".

Why platform-jobs (and not a bespoke cron)​

Platform-jobs already provides the runner, due-schedule query, claim/lease, recurrence, misfire policy, retries/backoff, and audit. The digest is one more handler + one schedule — no new scheduling infrastructure.

Target resolution​

v1 reads the targets from the schedule payload. The recommended follow-up is to derive targets automatically from the organizations/communities where notify-me is enabled (Part 8), so enabling the flag is the only action needed to onboard an org.

Acceptance criteria​

  • A daily schedule fires the handler at 09:00 org-tz and drives runDigestNow for each target (targetsProcessed).
  • A manual trigger runs the same path on demand.
  • A double-fire on the same day is absorbed by the run idempotency (Part 4).

Open questions​

  • Automatic target derivation from the FF store vs an explicit schedule payload.
  • Per-org send-time configuration (fixed 09:00 vs configurable).