Class RecurringSendScheduleSource
- Namespace
- MailFathom.Application.Mail.Delivery.Scheduling
- Assembly
- MailFathom.Application.dll
Declares one recurring dispatch for every message an owner asked to have sent again.
public sealed class RecurringSendScheduleSource : IScheduledJobSource- Inheritance
-
RecurringSendScheduleSource
- Implements
- Inherited Members
Remarks
The declarations are read from the database rather than from configuration, because that is where they are made: an owner writes a message and names a repetition, and neither is something an operator's file could hold. What the dispatch mechanism gets is the same shape a configured schedule gives it, so a message that repeats reaches the same worker, the same occasion arithmetic, the same one-run-at-a-time answer, and the same capacity bounds as a rule that does.
A declaration whose schedule no longer parses is left out rather than raised over. The syntax was read where the declaration was made, so a stored schedule that no longer parses is either a payload that was damaged or a build whose syntax has moved, and dispatching an occasion nobody can resolve is worse than dispatching none: what a deployment sees is a repetition that stopped, which is what the record itself says.
A cancelled declaration is not read at all, so it declares nothing from the moment it is stopped — including the occasion it would otherwise have produced next. The row it leaves keeps what it last did, which is what makes the stopping readable afterwards.
Constructors
- RecurringSendScheduleSource(IRecurringSendStore)
Initializes the source over the declarations this deployment holds.
Methods
- ReadSchedulesAsync(CancellationToken)
Reads the schedules this source declares as they stand now.