Purpose
Applications need durable background work with local storage or a shared SQL Server queue.
Execution model
Durability and execution
Jobs are durably accepted before handlers run. Recovery, leases and fencing coordinate work across restarts and SQL Server clients. Execution is at least once, so handlers with external side effects need idempotency or suitable fencing.
Scheduling and workflows
Supports delayed, interval, daily and cron scheduling, with timezone, overlap and misfire policies. Workflows are statically declared durable DAGs with explicit dependencies and dependency-failure policies.
Storage and management
Embedded storage fits a local application or machine. SQL Server lets multiple processes share a queue; each process executing work registers handlers and starts Basalt. BasaltDashboard is a separate WPF console; the management/monitoring API exposes health, queues, executions, failures, schedules, workflows, workers and cumulative statistics through the managed API.
Typical use
Quick start
using var basalt = Basalt.Embedded(@"C:\data\jobs");
basalt.On<SendInvoice>("billing.send", HandleAsync);
await basalt.StartAsync();
await basalt.EnqueueAsync(new SendInvoice(123), key: "invoice:123", retry: 5);Repository evidence
- README documents delayed, interval, daily and cron scheduling, static DAG workflows, retries, idempotent enqueue, recovery, leases and fencing
- README documents .NET 8 and .NET Framework 4.7.2 / WPF consumer support
- Management/monitoring documentation describes health, queue, execution, schedule, workflow and worker APIs; BasaltDashboard uses the managed API
- Durability documentation explicitly specifies at-least-once execution
Limits and status
- Execution is at least once; handlers with external side effects need idempotency or appropriate fencing
- SQL Server storage is not a worker service: each executing process registers handlers and starts the runtime
- BasaltDashboard is a separate WPF management console