Version v1.0 · dotnet

Provider Contract

Behavioral requirements every DurableStack storage provider must satisfy.

Provider Contract

All providers must implement the same functional contract so runtime behavior remains consistent.

The contract is represented primarily by IDurableJobStore and, for durable providers, IDurableStackStoreMigrator.

Required capabilities

  • Enqueue immediate and delayed runs.
  • Claim due runs safely with lease ownership.
  • Mark runs succeeded or failed with retry metadata.
  • Query runs by ID, status, and job.
  • Support recurring job state operations.
  • Support retention pruning behavior.
  • Extend run leases during execution heartbeat.

Distributed safety expectations

Durable providers must support safe concurrent claiming semantics so multiple workers do not actively process the same run under normal conditions.

Typical provider strategies include row locks and skip-locked style claim paths.

Migration and initialization

Durable providers are expected to support migration/init through IDurableStackStoreMigrator.

In-memory provider is an exception and uses a no-op migrator.

Table naming

Default logical table names:

  • durable_stack_jobs
  • durable_stack_job_runs
  • durable_stack_job_locks

When DatabaseTablePrefix is set, providers prepend the prefix to durable objects.