Kanject.Core.Recurring

Cron-style scheduled handlers, backed by EventBridge rules. Declare a class with [Recurring], deploy, and the schedule is provisioned automatically — no separate scheduler service.

Install

dotnet add package Kanject.Core.Recurring

Register

using Kanject.Core.Recurring.Extensions;

builder.Services.AddRecurringHandlers();   // discovers [Recurring] handlers via reflection

Define handlers

using Kanject.Core.Recurring.Abstractions.Attributes;

[Recurring(name: "subscription-renewals", cron: "0 3 * * ? *")]
public class SubscriptionRenewals(ISubscriptionService subs) : IRecurringHandler
{
    public Task RunAsync(CancellationToken ct) => subs.RenewDueAsync(ct);
}

[Recurring(name: "weekly-report", cron: "0 8 ? * MON *")]
public class WeeklyReport(IReportService reports) : IRecurringHandler
{
    public Task RunAsync(CancellationToken ct) => reports.SendWeeklyAsync(ct);
}

On kanject deploy, every [Recurring] class becomes an EventBridge rule (<stage>-<service>-<name>) targeting the same Lambda function. Removing the attribute removes the rule on next deploy.

What ships with it

• [Recurring(name, cron)] → EventBridge rule provisioned at deploy time
• Same DI container as HTTP handlers — singletons and scoped services reuse
• Per-handler timeout + retry policy via attribute parameters
• Failed runs land on a shared DLQ for inspection
• Local "fire once" runner via kanject test --recurring <name>