How long a claim is honored before reconciliation may reclaim the task.
Generous by default: the cost of a too-short TTL is a duplicate execution (a healthy but slow task gets reclaimed while still running), whereas the cost of a too-long TTL is merely delayed recovery after a crash. Long-running tasks extend it by heartbeat, so the TTL only has to exceed the heartbeat interval by a comfortable margin.
How often an in-flight task extends its own claim. Must be well below ClaimTTLSeconds.
Identifies this dispatcher instance in Task.ClaimedBy. Must be stable for the process
lifetime and distinct per instance — it is what lets reconciliation tell "my orphaned work"
from "another instance's live work".
Distinctness is a correctness requirement, not a nicety (C2). Every ownership guard in the
claim protocol compares against this value, so two instances sharing one defeats all of them
at once: A's heartbeat renews B's lease, and A's stale terminal write lands over B's live
execution. Host+pid is NOT sufficient — HOSTNAME is unexported to child processes under
systemd and pm2, and a containerised process is routinely pid 1 — which is why the server's
default appends real entropy.
Maximum tasks executed concurrently by this instance.
How often to look for claimable work.
Five seconds is the right production default — a graph's steps are agent runs measured in seconds to minutes, so polling faster buys latency nobody perceives and costs a query per instance per tick. It is configurable rather than fixed because the correct value genuinely differs by host: a test harness driving a graph to completion should not wait five seconds per node, and a deployment running many short tasks may want tighter latency.
How often the reconciliation sweep runs.
Tuning knobs for the durable dispatcher.