FabulousScheduler.Core 5.0.1

Core (FabulousScheduler.Core)

The FabulousScheduler.Core package holds the shared primitives that both subsystems build on. It contains no scheduling logic — only the contracts (IJob, IJobScheduler, IJobOk, IJobFail) and the JobResult<TOk, TFail> type.

For the high-level picture see General concepts.

📖 Contents

• IJob
• IJobScheduler
• IJobOk / IJobFail
• JobResult<TOk, TFail>

IJob <a id="ijob" />

FabulousScheduler.Core.Interfaces.IJob is the identity every job shares. It extends IDisposable and IAsyncDisposable.

The two subsystem interfaces extend IJob and add their own members:

• IRecurringJob — adds Category, State, SleepDuration, TotalRun, TotalFail, ExecuteAsync(). See Recurring.md.
• IQueueJob — adds State, TotalRun, Attempts, ExecuteAsync(), ResetState(). See QueueBased.md.

IJobScheduler <a id="ijobscheduler" />

FabulousScheduler.Core.Interfaces.IJobScheduler is the minimal scheduler contract; it extends IDisposable.

public interface IJobScheduler : IDisposable
{
    void RunScheduler();   // start the scheduler
}

Both IRecurringJobScheduler and IQueueJobScheduler extend it and add a JobResultEventHandler delegate / JobResultEvent for result callbacks (with subsystem -specific job and result types).

IJobOk / IJobFail <a id="results" />

The two markers carried by a result. Both expose only the job ID; concrete payloads (message, reason, exception) are added by the subsystem-specific implementations.

public interface IJobOk   { Guid ID { get; } }
public interface IJobFail { Guid ID { get; } }

⚠️ Design asymmetry: the queue JobFail derives from Exception, the recurring one is a plain class. Use them as result objects, not as things to throw.

JobResult<TOk, TFail> <a id="jobresult" />

FabulousScheduler.Core.Types.JobResult<TOk, TFail> (where TOk : IJobOk, where TFail : IJobFail) is a small discriminated union. It holds either a success value or a failure value, never both, and never uses exceptions for control flow.

Creating a result

A result is created implicitly from either side — you rarely call a constructor:

JobResult<JobOk, JobFail> ok   = new JobOk(id);                  // implicit -> success
JobResult<JobOk, JobFail> fail = new JobFail(reason, id, "msg"); // implicit -> failure

Inspecting

Consuming

// Side effect per branch
result.Do(
    success: ok   => Console.WriteLine("{0} succeeded", ok.JobID),
    failure: fail => Console.WriteLine("{0} failed: {1}", fail.JobID, fail.Message)
);

// Map to a value
string msg = result.Match(
    success: ok   => $"{ok.JobID} succeeded",
    failure: fail => $"{fail.JobID} failed: {fail.Message}"
);

// Async
int code = await result.MatchAsync(
    success: async ok   => { await Task.Yield(); return 0; },
    failure: async fail => { await Task.Yield(); return 1; }
);