openwhisk-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mark Deuser" <>
Subject Re: proposal to remove trigger activations when no rules are matched
Date Mon, 12 Feb 2018 17:35:02 GMT

I wanted to let you all know about a couple PRs [1] [2] that implement 
more of Rodric's proposal [3] to reduce unnecessary activation records. 
These PRs will update trigger fire behavior as follows:
  - [1] Only create a trigger activation record for a trigger if there is 
at least one active rule matched (and hence an action is invoked).

  - [1] Update the trigger activation record to include a "logs" field, 
which will be an array of JSON objects - with each object representing the 
action's non-blocking invocation results.  For example:
   "logs": [
     {"statusCode":0, "success":true, 
"activationId":"ae2d98c6b49b4a32ad98c6b49bba32c5", "rule":"guest/wrule", 
"action": "guest/echo-env-web"},
     {"statusCode":0, "success":true, 
"activationId":"32e3afff8a7f4c31a3afff8a7fbc319b", "rule":"guest/wrule2", 
     {"statusCode":1, "success":false, "rule":"guest/wrule3", "error":"The 
requested resource does not exist.", "action": "guest/nonexistent-action"}

  - [2] Return a 204 (no activation id payload) when a trigger is fired 
and it has no active rules.

  - [2] Update trigger activation "logs" field to include any inactive 
matched rules; however, there must be at least on active matched rule to 
create the activation record.

Minor changes to the "wsk" CLI will follow to handle trigger fire 
responses without activation ids.

Mark Deuser

From:   Rodric Rabbah <>
Date:   12/05/2017 11:20 AM
Subject:        Re: proposal to remove trigger activations when no rules 
are matched

Thanks Mark for picking this up. For the interested and future reference,
this is a sketch of the implementation that aligns with the proposal


On Tue, Dec 5, 2017 at 10:17 AM, Mark Deuser <> wrote:

> As part of the implementation of Rodric's proposal, a PR [1] has been
> submitted to the change the trigger fire API as follows:
>   - The trigger activation record will now be persisted asynchronously
>   - A 202 is returned instead of 200.  The activation id 
> continues to be returned in the body as before.
> This means that immediately after firing a trigger, the corresponding
> trigger activation may not yet be accessible - similar to today's
> asynchronous action invocation behavior.
> [1]

> Thanks,
> Mark Deuser
> On 2017-11-14 14:47, Rodric Rabbah <> wrote:
> >
> > This will require an API change: when a trigger is fired (assuming it>
> > exists, and the subject is authorized to fire it), today the 
> > will return 200 OK and an activation id. I propose instead to change
> the>
> > status code should to 202 Accepted if and only if the trigger has a>
> > corresponding active rule, an 204 No Content otherwise.>
> >

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