I’d propose we simply document a best practice that if you want to observe 
trigger firings, hook up the trigger to an echo action.

SJF

> On Nov 16, 2017, at 6:48 AM, James Thomas <[email protected]> wrote:
> 
> On 14 November 2017 at 19:47, Rodric Rabbah <[email protected]> wrote:
>> Today we create activation records for triggers regardless of a matching
>> rule. This can lead to many trigger activations that are not actually doing
>> anything useful. The system incurs the cost of creating the activation
>> record and no actions are run.
> 
> As a user, I do find it useful to see trigger activations, even when
> I've not yet attached a rule. It helps me see I've set up the trigger
> feed correctly, with the event parameters being logged.
> It would be more difficult if I could only check the activations by
> creating a "no-op" action to attach.
> 
> What would happen with rules that are disabled?
> 
> If this issue is happening for triggers, would future load from other
> invocations (actions, rules) eventually encounter the same issue?
> 
> I can understand trigger invocations will be a significant load on the
> backend, as people leave old triggers connected to feeds. Removing
> this does make the "developer experience" worse IMO. It'll be a
> trade-off between this and performance unless there's a more scalable
> way to manage the activation records.
> 
> 
>> I'd like to consider this as a first step as part of a larger item that can
>> be encompassed by https://github.com/apache/incubator-openwhisk/issues/512.
>> 
>> A subsequent step that I'd like to propose is to eliminate the separate
>> rule activation record. Instead, the controller should record the matched
>> rules in the trigger activation record (either as synthetic logs akin to
>> sequences or as annotations) along with the activation ids of all caused
>> invocations. Currently there is no visibility to the client in terms of the
>> activations ids that are caused by a rule, and this leads to a poor user
>> experience.
> 
> This sounds good.
> 
> -- 
> Regards,
> James Thomas

Reply via email to