Skip to content

Guided tour

FabrCore 2.0 · Release and package availability

These guides track the current 2.0 source. Stable 2.0.0 publication is pending; package commands show the release target. Until it is published, follow the source quick start or use a matching available prerelease set. Release migration · Runtime modes

MODULE 04 · LESSON 4.5

Schedule work and manage agent lifetime

Schedule work with the right lifetime and recovery assumptions.

Lesson 20 of 86 · FabrCore 2.0

Overview

Timers serve active-process work. Reminders are scheduled through Orleans and are durable only when the configured reminder provider is durable. Reset/reconfigure, deactivation, thread clearing and eviction have different effects and should not be interchangeable UI actions.

Timers require a live activation

A timer is useful for a short periodic action while an agent is active. It is not a promise that work will execute after the process exits. A reminder is registered with Orleans and can be recovered according to its reminder provider. A durable registration still needs idempotent business logic: a retry must not accidentally send a second notification or repeat a write.

Lifecycle actions are not interchangeable

Restart/reconfiguration reconstructs behavior using configuration and stored state. Reset can clear conversation or custom state. Eviction removes runtime/persisted agent state rather than merely pausing it. Choose an operation based on what should be retained. If a runbook says “restart to fix it,” make the intended retained state explicit before implementing the button.

Choose a scheduling lifetime

  1. Use a timer for short local polling and a reminder for a persisted scheduled operation. Inject TimeProvider for deterministic scheduling tests.
  2. Expose lifecycle actions with their effects: reconfigure changes behavior, deactivation allows later activation, and hard eviction removes the instance's durable state.
  3. Record business operation identity before external work so a repeated reminder can check whether its effect already occurred.
Timers (Non-Persistent) · reference snippet
// In OnInitialize or OnMessage
fabrcoreAgentHost.RegisterTimer(
    timerName: "health-check",
    messageType: "timer:health-check",
    message: null,
    dueTime: TimeSpan.FromMinutes(1),
    period: TimeSpan.FromMinutes(5));

// Timer fires come as regular messages in OnMessage
public override async Task<AgentMessage> OnMessage(AgentMessage message)
{
    if (message.MessageType == "timer:health-check")
    {
        var response = message.Response();
        response.Message = "Health check complete";
        return response;
    }
    // Normal message processing...
}

// Unregister
fabrcoreAgentHost.UnregisterTimer("health-check");
Reminders (Persistent) · reference snippet
await fabrcoreAgentHost.RegisterReminder(
    reminderName: "daily-report",
    messageType: "reminder:daily-report",
    message: "Generate daily summary",
    dueTime: TimeSpan.FromHours(1),
    period: TimeSpan.FromHours(24));

// Override in your agent
public override Task OnReminder(string reminderName)
{
    if (reminderName == "daily-report")
    {
        // Perform periodic check
    }
    return Task.CompletedTask;
}

await fabrcoreAgentHost.UnregisterReminder("daily-report");

Test firing, restart and duplicate handling

  1. Register a short development timer and record its callbacks with an operation identifier. Stop the Host; callbacks must stop too.
  2. Test a reminder with a durable provider when available, restarting before its next due time. Record the resumed callback and the registration that caused it. In-memory standalone cannot prove durable reminder recovery.
  3. Arrange for the same business operation identifier to be observed twice in a test. Your application should reconcile or deduplicate the effect rather than assume scheduling guarantees exactly-once work.

The visible record should explain what ran, which registration caused it, and what persisted. Scheduling reliability depends on provider durability and the business operation's retry behavior.

If the result is different

Do not expect a standalone reminder to survive process death. A recovered schedule is not automatic exactly-once business execution.

Go deeper

Explore the related documentation.