Openwhisk: [Feature Request] Include activation ID in web action header.

[style95]

Environment details:

• Any

Steps to reproduce the issue:

1. Invoke a web action.

Provide the expected results and outputs:

function main(params) { 
    return { response: params };
}

curl -X GET 'localhost/api/v1/web/myNamespace/hello.json'
{
  "response": {
    "__ow_method": "get",
    "__ow_headers": {
      "accept": "application/json, text/plain, */*",
      "activation_id": "ebc60b3553c14046860b3553c1c0464a"  # This is required
       .
       .
       .
    },
    "_": "1524725954543",
    "__ow_path": "",
  }
}

Provide the actual results and outputs:

curl -X GET 'localhost/api/v1/web/myNamespace/hello.json'
{
  "response": {
    "__ow_method": "get",
    "__ow_headers": {
      "accept": "application/json, text/plain, */*",
       .
       .
       .
    },
    "_": "1524725954543",
    "__ow_path": "",
  }
}

Additional information you deem important:

Currently activation ID is not passed when the action is a web action.
When user want to retrieve more detail information about the activation, it's not easy to pick the right one from activation list API if there are subsequent action invocation calls.
So it would be great if server returns activation ID in headers or via any other ways.

[markusthoemmes]

Great idea! To broaden this up a bit: Shall we report the activation ID as a header in any request that generates an activation ID (trigger fire, blocking invokes).

[rabbah]

Markus, Dominic have you thought about using the request id (aka tid) as the activation id? This would avoid creating a new activation id is several cases, and is already in the header thanks to recent changes.

[style95]

@rabbah Yes I have seen transaction id is included in X-Request-Id, if it is ok to override it using activation id, I will work on it.

[rabbah]

I’m not suggesting we do that yet was wondering if someone else has given it some thought. There may be some unintended implications to think about.