openwhisk-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tyson Norris <>
Subject Re: Passing TransactionId as part of action invocation
Date Wed, 21 Aug 2019 17:08:59 GMT
I think the point of transaction id in this case is to correlate multiple activations, similar
to how a sequence works, but not relying on sequence as the mechanism for doing this. 

Today, if you launch many activations explicitly, e.g. using OW SDK in your nodejs action,
they are not "related" to each other, and this would offer a way to work around that. Initially,
just storing the transaction id, means that operators can create queries to stitch multiple
activations that originated from the same request. It would also be possible to expose transaction
id to users in the same way that activation id is using a first class API, maybe as part of
the existing activation API, e.g. GET o/api/v1/namespaces/_/activations?tid=<transactionid>

Users can certainly use APIs wrong, but with decent documentation, I don't think this should
dissuade us from providing the feature.


On 8/21/19, 8:16 AM, "Martin Henke" <> wrote:

    from an operational point of view I have some fear that we will confuse the user by making
the transaction id visible as a second id besides the 
    activation id. 
    Some will certainly use it to fetch activation records and fail, which will lead to questions.
    Any thoughts from your side ?
    > On 20. Aug 2019, at 12:32, Chetan Mehrotra <> wrote:
    > I created a separate thread to discuss how to store such metadata related
    > to activation.
    > Current open PR #4586 only enables exposing the transactionId to env. It
    > does not make any attempt to store the transactionId currently. Once we
    > decide how such data should be stored then I can open PR for  the same
    > Chetan Mehrotra
    > On Mon, Aug 19, 2019 at 8:47 AM Rodric Rabbah <> wrote:
    >> Yes indeed. Your pr already open I think is fine as is.
    >> -r
    >> On Aug 19, 2019, at 11:36 AM, Chetan Mehrotra <>
    >> wrote:
    >>>> That’s true. Time for api/v2...
    >>> This is now becoming a rabbit hole! What option should we use without
    >> going
    >>> for v2?
    >>> 1. Introduce a new "meta" sub document
    >>> 2. OR Change annotations to flat map while storing but transform that to
    >>> array based structure while returning to client
    >>> Chetan Mehrotra
    >>>> On Mon, Aug 19, 2019 at 7:15 AM Rodric Rabbah <>
    >>>>> However changing them now would cause compatibility
    >>>>> issue with various tooling out there which may be interpreting the
    >>>>> annotation per current design
    >>>> That’s true. Time for api/v2... 😅

View raw message