- Shipped
- September 2, 2026 at 5:22 AM UTC
- Author
- Kamo
- Commit
- 1b5f575
One internal endpoint, X-Internal-Auth gated and constant-time compared, that DaemonService ticks. The cron stays in the daemon because it is replicas: 1 with strategy Recreate, so a deploy window cannot double-fire; a @Scheduled in a service that rolls with surge provably can, and there is no ShedLock anywhere in this fleet. For a job whose output is an organization's figures emailed to a list of addresses, "usually once" is not a property. Every schedule runs as its OWNER, with rights recomputed at run time from their stored grants — not as the daemon, which has none, and not as whoever last edited the schedule. So revoking somebody's access stops their schedules producing data they should no longer see at the very next run, rather than whenever a session expires. Without that, a schedule is a way to have the server read data on your behalf that you could not read yourself. nextRunAt is advanced BEFORE delivery is attempted. A crash mid-delivery then costs one missed send rather than an unbounded loop of duplicates, and a missed weekly report is a far cheaper failure than the same report arriving forty times. The rendered file goes as an attachment rather than a link, because these are routinely sent to a client or an accountant with no account. One bad address does not cost the other recipients their report, but a run where every address failed is recorded FAILED rather than delivered-to-nobody. An empty report is not sent unless the owner asked for it: a weekly email that always arrives stops being read.