openwhisk-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dragos Dascalita Haut <>
Subject Passing a context object to actions
Date Sat, 07 Jan 2017 01:04:07 GMT

These days I've been doing some work on creating an OpenWhisk action directly from a GitHub
repo - issue link [1] ; initial implementation [2] . After successfully deploying a "hello-world"
action - [3] I thought about updating the message with some information from an OAuth token.
I've used the API Gateway to decorate the request with a "context" object. To achieve this
I had to merge the context with the actual event payload. I've posted the snippet of the API
Gateway code at [4] in a gist. Things are working fine and here is a sample of a response
from the action; note the "context" object which was added by the API Gateway.


  "payload": "Hello, 1FF62BDC53C3662B from branch-1 !",

  "event": {

    "context": {

      "identity": {

        "user_id": "1FF62BDC53C3662B",

        "client_id": "demo_app",

        "scope": "openid,avatar"





As a result of this experience I've learned a few things out of which the most important one
that I'd like to open a discussion here on the list is: the mechanism to pass a context to
an action.

At the moment the only way is to decorate the event with extra fields and I see a few drawbacks
to this approach:

  * The fact that we need to unpack the request body and change it has an impact on performance

  * If we want to send binary payloads in a special format, the API Gateway or some other
process in the middle has to know how to decode/encode that payload/Content-Type. So we're
limited to what these intermediary processes know.

The same thing happens with default action parameters; they get merged with the event. Basically
besides the event itself there's no other way to configure the action with extra params or
pass it a context.

I'd like to get your feedback to see if we're ok to enhance the existing mechanism.

As an example,  AWS Lambda allows a similar mechanism to pass a "context" to a function. See
[5]. Clients can provide a custom "clientContext" object . Besides this object, the AWS API
Gateway also adds its own fields into the "context" object; see [6].

If we want, we could take a similar approach. The way it works in AWS is through headers.
For instance the "clientContext" is passed as a Base64 JSON-encoded header.

In OpenWhisk actions the main method signature would allow 2 params instead of 1 (as it is
today) and it could look like:

function main(event, context)

The clientContext would be accessible as:


And context.identity.* would be something reserved for the OpenWhisk API Gateway to populate
and it could also be based on special headers like "X-GW-Identity".

What I like about this approach with Headers is that no intermediary process needs to understand
the body of the request; we could also support multiple content types easier as well.



dragos dascalita haut | project lead, software development | adobe cloud platform

[1] -
[2] -
[3] -
[4] -
[5] -
[6] -

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message