+1 to Rodric’s proposal Making the controller do waist work and backend save data for useless is not good.
James what Steven proposed is a very simple way to test a trigger when you get started. Also what Rodric is proposing would allowed what you requested to have event causality meaning we would record in action activation which trigger activated the action. On Thu, Nov 16, 2017 at 6:50 AM Stephen Fink <fink.step...@gmail.com> wrote: > 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 <jthomas...@gmail.com> wrote: > > > > On 14 November 2017 at 19:47, Rodric Rabbah <rod...@gmail.com> 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 > >
