Job Dependency

[linkdotnet]

Currently this is more of an extensive draft rather than a PR. Basically, this PR tackles #46 to a greater extent.

The Core Idea

The idea is to define job dependencies like this:

builder.Services.AddNCronJob(n => n
    .AddJob<MyJob>(p =>
        p.WithCronExpression("*/20 * * * * *", timeZoneInfo: TimeZoneInfo.FindSystemTimeZoneById("Pacific Standard Time")))
    .When(success: d => d.RunJob<PrintHelloWorldJob>("Success"), faulted: d => d.RunJob<PrintHelloWorldJob>("Faulted"),)

So, one job type can define 0..n dependencies that will run after the job has finished. We only distinguish between "success" and "faulted".

• Faulted: The principal job did throw an exception
• Success: No exception thrown

The newly dependent job will get the output of the principal job (ParentOutput) as part of the JobExecutionContext. I was thinking of widening that to have the following API:

public sealed record JobExecutionContext(Type JobType, object? Parameter)
{
 + public JobExecutionContext? ParentContext { get; set; }
}

At least that seems less arbitrary in terms of what we do and don't push down to dependent jobs.

In theory the user can define a job graph as such:

flowchart LR
    Job1 -- Success --- Job2
    Job1 -- Failure --- Job3
    Job1 -- Success --- Job4
    Job2 -- Success --- Job5
    Job2 -- Failure --- Job6

1. We allow multiple RunJob<TJob> inside one When clause - chaining multiple jobs and pushing multiple jobs into the queue.
2. Allowing multiple AddJob with When(s => s.RunJob) to chain them further.

I do think that is the right balance between over flexibility and a solution that is too simple.

Refactorings

In the same term, I refactored some of our types. I extracted some of the logic and moved some bits here and there. Mainly, I introduced a JobQueue, which is the sticky part between the QueueWorker (formerly CronScheduler) and the JobExecutor).

Current open topics

• [ ] The job inside RunJob will not automatically be registered. Still, the user has to call AddJob somewhere. Maybe we want to change that as it seems arbitrary.
• [ ] There are absolutely zero tests at the moment
• [ ] And zero documentation
• [ ] I have to double check if our Concurrency-Model and so on is still doing what it should do

[linkdotnet]

@falvarez1 I am more and more inclined to merge that PR. It basically doesn't only add the feature but also

• Fixes #52, as we now go over the same central entity in every case (JobQueue and QueueWorker).

Also, I renamed a few things, but I will annotate a few things that might need some polishing.

[linkdotnet]

One thing that bothered me in this PR I’d that we don’t distinguish between a JobDefinition and a JobRun. while not crucial now, i do feel more and more pressure to have those two objects

[falvarez1]

One thing that bothered me in this PR I’d that we don’t distinguish between a JobDefinition and a JobRun. while not crucial now, i do feel more and more pressure to have those two objects

Yes I agree we need a clear definition and needs to be distinct, this is necessary for the observability for dashboard etc.

Both Jobs and a Job Runs need their own definition.

[linkdotnet]

I will pick the good parts here and close the PR. The PR did too much anyway.