Scheduling

If you want the implementation flow instead of the reference view, start with Scheduling Workflow.

Feature activation

nestforge = { version = "1", features = ["schedule"] }

Core types

Scheduling support is built around:

• ScheduleRegistry
• ScheduleRegistryBuilder
• start_schedules
• shutdown_schedules

Registration pattern

The standard approach is to register a ScheduleRegistry provider and start it during application bootstrap:

#[module(
    providers = [build_schedule_registry()?],
    on_application_bootstrap = [nestforge::start_schedules],
    on_application_shutdown = [nestforge::shutdown_schedules]
)]
pub struct AppModule;

Job types

The current registry supports:

• repeated jobs with every(...)
• one-shot delayed jobs with after(...)
• named variants with every_named(...) and after_named(...)

You can build the registry inline:

use std::time::Duration;
use nestforge::ScheduleRegistry;

fn build_schedule_registry() -> anyhow::Result<ScheduleRegistry> {
    Ok(
        ScheduleRegistry::builder()
            .every_named("metrics", Duration::from_secs(30), || async {})
            .after_named("warmup", Duration::from_secs(5), || async {})
            .build(),
    )
}

Practical use

Scheduling belongs in modules when the jobs are part of application behavior, not as hidden global threads. This keeps lifecycle and shutdown behavior explicit.