title of the context
user-context
broadcasting channels
parent context if not root
Context's children
timestamp corresponding to the instance creation
a reference timestamp, use this.startTimestamp if not provided
Either the 'true' elapsed time of this context if it has ended or the maximum elapsed(this.startTimestamp) of the children (recursive lookup)
End the context manually when startChild has been used to create it (in contrast to withChild).
Used for asynchronous scenarios.
Log an ErrorLog.
the error
some data to log with the error
Log an InfoLog.
info
some data to log with the info
the root context of the tree
Start a new child context, supposed to be used in asynchronous scenarios.
The attribute userContext of the child context is a clone of the parent's user-context, eventually merged with provided withUserContext. withUserContext is needed for very specific cases, usually there is no need to provide one.
title of the child context
user context entries to add
the child context
whether the context is ContextStatus.RUNNING, ContextStatus.SUCCESS or ContextStatus.FAILED
Log a WarningLog.
description of the warning
some data to log with the warning
Wrap a new child context around a callback, supposed to be used in synchronous scenarios. In this case the developer does not need to handle start or end of the child context.
The attribute userContext of the child context is a clone of the parent's user-context, eventually merged with provided withUserContext. withUserContext is needed for very specific cases, usually there is no need to provide one.
If an error is thrown and not catched during the callback execution, the child context end (along with its parents), the error is reported in the child context, and finally the error is re-thrown.
title of the child context
the callback, the child context is provided as argument of the callback
the child context
Generated using TypeDoc
Context
Context objects are used to essentially track the execution flow of some processing functions, essentially to:
Context can be used in synchronous or asynchronous scenarios, the following example illustrates both usages (code is simplified to only keep the relevant points):
The difference between sync. and async. scenario is whether or not it is needed to call context.close:
The natural representation of a context, as presented in Flux applications, is a tree view representing the tree structure of the chain of function calls. The children of a context can be of two types:
Logs broadcasting
Context objects can feature broadcasting channels$ to multiple destinations and with different filters through LogChannel. For instance, [[ModuleFlux]] use two channels:
A note about user-context
The Context object also conveys the user-context. The user-context is a key->value dictionary filled by the builder of a Flux application (using adaptors) that needs to be forwarded from modules to modules. The library can not automatically forward the user-context when output are sent: it is not always as meaningful as expected (e.g. what is the output context of a combining type of module?), and the asynchronous (possibly multi-threaded) nature of module's processes makes it impossible (meaning we did not find a safe way of doing so 🤫).
This explains why, when emitting a value through an output pipe, you should explicitly pass back the context that has been provided for you at the first place (to the onTriggered callback).