As discussed in the
WfRun documentation, a
WfRun can have multiple
ThreadRuns. The main thread is called the Entrypoint Thread, and all other threads are children (or grandchildren) of the entrypoint.
WfSpec defines one or more
ThreadSpecs, and the corresponding
WfRun has one or more
ThreadRun has a corresponding
ThreadSpec in the
ThreadSpec is special: it is the
ENTRYPOINT thread. Similarly, each
WfRun has a special
ENTRYPOINT thread run.
When you run a
WfSpec (thereby creating a
WfRun), the resulting
WfRun is created with one entrypoint
ThreadRun, which (as you guessed) is specified by the entrypoint
ThreadSpec of the
WfRun may have multiple
ThreadRuns in it.
ThreadRuns have four types:
ENTRYPOINTthreads, described above.
CHILDthread, created explicitly via a
SPAWN_THREADnode (in Java, for example,
INTERRUPTthread, triggered by an External Event.
FAILURE_HANDLERthreads, which are akin to exception handlers in programming.
ThreadRuns other than the entrypoint thread will have a
parentThreadId, referring to the thread that spawned it. In the case of an
INTERRUPT thread, the parent thread is the thread that was interrupted; in the case of a
FAILURE_HANDLER thread, the parent is the thread whose failure triggered the exception handler.
ThreadSpec can define
Variables (for example, through the
variableDefs field in the JSON spec, or
WorkflowThread::adVariable() in Java). When a
ThreadRun is created, all defined
Variables are instantiated (either with input values or as
When a child
ThreadRun of any type is started, it has read and write access to its own
Variables, and all
Variables that its parent has access to (including the parent's parent, and so on).
ThreadRun can have multiple children, the parent does not have access to the variables of the children.