Hi Rodric, The term "transaction id" is ambiguous. It can be interpreted, for example, as a grouping label for a distributed transaction, not necessarily one that befits a sequential flow. "Flow id" seems to be a clearer definition, and more generic, in the sense that a transaction can "ride" on a flow, just like all the other examples below.
My point in the list of examples below is that all these can be future enhancements, and they are all enabled by the basic mechanism of associating a flow with additional meta data. Thus, we should not restrict the design to only one particular use case such as transactions (which is what I understood "transaction id" to be at first). -- Erez From: Rodric Rabbah <rod...@gmail.com> To: dev@openwhisk.apache.org Date: 22/08/2019 13:20 Subject: [EXTERNAL] Re: Passing TransactionId as part of action invocation > Here are a few more examples of "meta" information, other than transaction > id. > - QoS (e.g., to affect scheduling) > - URL of specific log channel (e.g., to consolidate logs across a chain of > invocations) > - Flow ID (e.g., for tracing) > - Debug flag (e.g., to enable step-into interactive debugging) Unlike the transaction id (flow id?), these are all properties that don?t exist today in the control plane. -r
