Type Members

1.  trait =:!=[A, B] extends AnyRef

   Annotations

   @nowarn()

2.  trait CircuitBreaker extends AnyRef
3.  final case class DefaultOperationExecutor(env: ZEnvironment[Client], policies: HttpOperationPolicies, perHostRetryLogic: TMap[String, TPromise[Nothing, HttpRetryLogic]]) extends OperationExecutor with Product with Serializable
4.  class HttpRetryLogic extends AnyRef
5.  final case class InMemoryRemoteContext(store: TMap[RemoteVariableName, DynamicValue], configuration: Configuration) extends RemoteContext with Product with Serializable
6.  final case class PersistentExecutor(execEnv: ExecutionEnvironment, durableLog: DurableLog, kvStore: KeyValueStore, persistentState: PersistentState, operationExecutor: OperationExecutor, workflows: TMap[FlowId, Promise[Nothing, RuntimeState]], gcQueue: Queue[GarbageCollectionCommand], flowScope: Scope) extends ZFlowExecutor with Product with Serializable
7.  final case class PersistentRemoteContext(virtualClock: VirtualClock, remoteVariableStore: RemoteVariableKeyValueStore, executionEnvironment: ExecutionEnvironment, scope: RemoteVariableScope, scopeMap: TMap[RemoteVariableName, RemoteVariableScope]) extends RemoteContext with Product with Serializable
8.  trait PersistentState extends AnyRef
9.  trait Persister extends AnyRef
10.  trait RecordingRemoteContext extends AnyRef
11.  final case class RemoteVariableKeyValueStore(keyValueStore: KeyValueStore, readVariables: TSet[ScopedRemoteVariableName], executionEnvironment: ExecutionEnvironment, durableLog: DurableLog, lastIndex: TRef[Index]) extends Product with Serializable
12.  sealed trait RemoteVariableScope extends AnyRef

    Describes a remote variable's scope

    Describes a remote variable's scope

    ## Scoping rules

    ### Workflows A top level workflow defines the top level scope by it's unique flow identifier. This guarantees that:

    • separate workflows cannot see each other's variables
    • restarted workflows see the same set of variables as the previous run as they share the flow id

    Operation semantics on the top level of workflows (not in a forked fiber and not in an active transaction):

    • New(name): creates a new remote variable in the KV store's variable namespace called "$$flowid$$name"
    • Get(name): reads"$$flowid$$name"
    • Set(name): writes"$$flowid$$name"

    ### Fibers Forked workflows are like regular workflows but they are not individually submitted, instead created by the executor by the Fork operator.

    Each workflow maintains a fork counter and generates new workflow ids based on that. So a forked workflow's flow identifier will be "$$parentId_fork$$parentForkCounter".

    Desired semantics:

    • Forked workflows should have read/write access to variables accessible to the parent workflow
    • Creating new variables in a forked workflow should not be accessible to the parent and sibling workflows
    • Parallel forked workflows should be able to create independent variables with the same name

    Operation semantics in forked workflows:

    • New(name): creates a new remote variable in the KV store's variable namespace prefixed by the active workflow identifier "$$flowid$$name" (which is "$$parentId_fork$$parentForkCounter$$name").
    • Get(name): first finds the variable's scope by first looking in the current fiber's scope (using "$$flowid$$name") - if it does not exist, it recursively tries to access the variable in the parent scope ("$$parentid$$name").
    • Set(name): same lookup as for Get - Get and Set must always select the same variable in an executor step

    ### Transactions

    In transactions we have to delay the effect of Set (but within the transaction still see that value in Get) until the transaction is committed. This means that we need to store values for the same remote variable name per transaction beside its original value - which means transactions define their own scope.

    Desired semantics:

    • Creating a new variable in a transaction: should not behave differently than in a regular scope
      • transactional variable updates are only interesting if there are multiple fibers running transactions modifying the same variable. This means that even if there are "colliding" new variables in parallel transactions, their parent scope will be different (because fibers are also defining scopes) so they would never collide.
    • Within the transaction, Get and Set should work as usual, but the effect of Set should not be visible for other fibers, even if the changed variable is in a shared scope.
    • When the transaction is committed, the changes are either applied to these shared variables, or the transaction gets reverted.

    Flow state contains a transaction counter that can be used as a unique identifier for transaction scopes, similar to how fiber scopes are generated: "parentId_tx$$transactionCounter".

    Operation semantics in transaction scopes:

    • New(name): creates a new remote variable in the parent scope
    • Get(name): acts the same way as in forked workflows, but also records the accessed variable's version if necessary
    • Set(name): always sets the value in the transaction scope ($$parentid$$name)
13.  final case class ScopedFlowId(name: FlowId, parentStack: List[FlowId]) extends Product with Serializable
14.  final case class ScopedRemoteVariableName(name: RemoteVariableName, scope: RemoteVariableScope) extends Product with Serializable
15.  sealed trait TransactionFailure[+E] extends AnyRef
16.  trait VirtualClock extends AnyRef