#Process execution

Chester executes a deployed process event-driven, distributing each step to its workers.

You do not operate the engine directly. What follows is the behaviour that shows up in what you model and in what you see in monitoring.

#What happens to a step that fails

Opening a run shows what each step did. A step that fails is retried automatically with a growing delay; when its attempts run out the run stops here, and you can correct the input and retry it by hand.

Three retries by default — four attempts in all — and never more than ten. A broken expression or an incomplete configuration skips the retry loop entirely and goes straight to the stopped state, because a second attempt would fail identically. Only steps that call a system — service tasks, send tasks, message throws — are retried automatically; other steps stop at their first failure.

#A step may run more than once

Chester guarantees that every step is delivered at least once, not exactly once. Under a retry or a restart, a step can be attempted again.

This matters when you model something with an outside effect. "Create an invoice" should be written so that running it twice does not produce two invoices — by using an identifier the external system can recognise, for example. Chester deduplicates what it can, but only the external system knows whether two calls are the same act.

#Failures are retried, then set aside

A failed step is retried automatically with a growing delay between attempts — by default three retries, and never more than ten. A step that still fails is stopped and surfaced in monitoring, where you can correct the input and retry it by hand.

Retrying is the default, including for an error the external system will return again. A request the external system rejects is retried like any other failure. If a call should not be repeated, the process has to express that — by checking the response and routing the failure itself, rather than relying on Chester to tell a permanent refusal from a temporary one.

The exception is a broken expression, which stops immediately: it is deterministic, so a second attempt would fail identically.

#Waiting does not hold anything open

A process waiting for a person, a timer or an incoming message is not occupying a worker. It is parked until the thing it waits for arrives, so a process can sit at an approval step for days without that costing anything to keep alive.

#The first event wins at an event-based gateway

At an event-based gateway the process waits for all of the following events at once, and the first one to happen decides the path. The others stop waiting at that moment; one that arrives later is ignored, and nothing continues on its path. In the instance view the event that won continues its path, and the events that lost show as interrupted.

#Parallel branches really are parallel

Branches and multi-instance loops run at the same time, potentially on different workers. Their results are collected independently, so two branches writing their own outputs cannot overwrite each other.