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
