executor

type Config ¶

type Config struct {
	// contains filtered or unexported fields
}

type Executable ¶

type Executable struct {
	// contains filtered or unexported fields
}

Executable is an implementation of the Executor interface. It uses a schedule.Scheduler to mark the next job's execution time, and supports multiple Runner.

func (e Executable) Exec(ctx context.Context) error

func (e Executable) ID() string

func (e Executable) Next(ctx context.Context) time.Time

type Executor ¶

type Executor interface {
	// Exec runs the task when on its scheduled time.
	//
	// For this, Exec leverages the Executor's underlying schedule.Scheduler to retrieve the job's next execution time,
	// waits for it, and calls Runner.Run on each configured Runner. All raised errors are joined and returned at the end
	// of this call.
	Exec(ctx context.Context) error
	// Next calls the Executor's underlying schedule.Scheduler Next method.
	Next(ctx context.Context) time.Time
	// ID returns this Executor's ID.
	ID() string
}

Executor describes the capabilities of cron job's executor component, which is based on fetching the next execution's time, Next; as well as running the job, Exec. It also exposes an ID method to allow access to this Executor's configured ID or name.

Implementations of Executor must focus on the logic of the Exec method, which should contain the logic of the Next method as well. It should not be the responsibility of other components to wait until it is time to execute the job; but actually the Executor's responsibility to consider it in its Exec method. That being said, its Next method (just like its ID method) allows access to some of the details of the executor if the caller needs that information; as helpers.

The logic behind Next and generally calculating the time for the next job execution should be deferred to a schedule.Scheduler, which should be part of the Executor.

One Executor may contain multiple Runner, as a job may be composed of several (smaller) tasks. However, an Executor is identified by a single ID.

func AddLogs(e Executor, handler slog.Handler) Executor

func AddMetrics(e Executor, m Metrics) Executor

func AddTraces(e Executor, tracer trace.Tracer) Executor

func New(id string, options ...cfg.Option[Config]) (Executor, error)

func NoOp() Executor

type Metrics ¶

type Metrics interface {
	// IncExecutorExecCalls increases the count of Exec calls, by the Executor.
	IncExecutorExecCalls(id string)
	// IncExecutorExecErrors increases the count of Exec call errors, by the Executor.
	IncExecutorExecErrors(id string)
	// ObserveExecLatency registers the duration of an Exec call, by the Executor.
	ObserveExecLatency(ctx context.Context, id string, dur time.Duration)
	// IncExecutorNextCalls increases the count of Next calls, by the Executor.
	IncExecutorNextCalls(id string)
}

Metrics describes the actions that register Executor-related metrics.

type Runnable ¶

type Runnable func(ctx context.Context) error

Runnable is a custom type for any function that takes in a context.Context and returns an error. This type of function can be perceived as a Runner type. For that, this custom type will implement Runner by exposing a Run method that invokes the actual Runnable function.

func (r Runnable) Run(ctx context.Context) error

type Runner ¶

type Runner interface {
	// Run executes the job or task.
	//
	// This call takes in a context.Context which may be used to denote cancellation or closure (e.g. with a timeout)
	//
	// The returned error denotes the success state of the execution. A nil error means that the execution was successful,
	// where a non-nil error must signal a failed execution.
	Run(ctx context.Context) error
}

Runner describes a type that executes a job or task. It contains only one method, Run, that is called with a context as input and returns an error.

Implementations of Runner only need to comply with this method, where the logic within Run is completely up to the actual implementation. These implementations need to be aware of the state of the input context.Context, which may denote cancellation or closure (e.g. with a timeout).

The returned error denotes the success state of the execution. A nil error means that the execution was successful, where a non-nil error must signal a failed execution.