Make agents propagate events immediately

[qedi-r]

This should be the first step to resolving #157

• adds new propagate_immediately field to database
• alters Agent base class to be able to receive! based on a list of certain agent ids
• alters Event class to call receive! when new events are created, when the receiving agent has propagate_immediately set
• adds field to agent page
• two rspecs to test basic functionality

[cantino]

I don't think you need this accessor anymore, because now it's on the Agent.

[cantino]

Nice work!

Have you ran this for a while and seen that the propagation works the way we expect?

[qedi-r]

So far, yes. Though I don't have much more than a toy setup, currently.

[cantino]

I'll try running it on my setup for a few days.

[cantino]

Whoops, specs are failing.

[cantino]

Hey @qedi-r, it looks like there is an error in the build.

[qedi-r]

Oops. Missed one last line of the unused propagate_immediately in events...

[cantino]

Nice! I will test this for a few days with my Huginn setup, then merge it.

[cantino]

Is this inside of the same control-group as sources for any particular reason? Could you move it to a separate one so that it sits on one line?

I think this would work:

<div class="control-group">
  <% f.label :propagate_immediately, :class => 'control-label' do %>
    <%= f.check_box :propagate_immediately %>
  <% end %>
</div>

You may need a tiny but of CSS so that it's vertically centered.

[cantino]

Oh, it's in the same group because it only makes sense if an Agent has sources, right?

Could you put the checkbox and label on the same line, perhaps by nesting them as in my code above?

[qedi-r]

I don't think if separating it out into it's own control-group is necessary, so that isn't part of this, otherwise, the label makes more sense now.

[cantino]

It's been working well for me, so I'm going to merge it. Nice work!

[bennlich]

Might be nice to add a tooltip to the web interface explaining what this option does. I'd be up for adding the tooltip, but I'm not totally sure what it should say.

[cantino]

Good idea. That'd be great if you could add one! Maybe something like "Selecting this option causes any listening Agents to receive the event immediately without waiting for a scheduled propagation. Be sure to avoid loops."

[elsurudo]

So just to be clear, "propagate immediately" is set on the creating agent (push semantics), correct? Just some confusion because I believe #157 seemed to suggest otherwise.

In any case, I think it may be useful to also have a similar setting to be set on the receiving agent (pull semantics), so when a scheduled even occurs, it can set off a chain-reaction of events in order to fetch the data it needs.

For example, I have a "Get Weather" agent that fetches conditions at 5am, and then a "Morning Digest" agent at 6am. By the time I get the weather, it's already an hour out-of-date. This would rectify that issue.

Thoughts?

[cantino]

Hey @elsurudo, actually this is pull semantics, and I agree it's a bit confusing.

We have a after_create :possibly_propagate in Event, which looks like this:

  def possibly_propagate
    #immediately schedule agents that want immediate updates
    propagate_ids = agent.receivers.where(:propagate_immediately => true).pluck(:id)
    Agent.receive!(:only_receivers => propagate_ids) unless propagate_ids.empty?
  end

This is actually looking at the creating Agent's receivers and pushing the event to any that have requested immediate propagation.

[elsurudo]

I see. I would still call that push semantics, with the only difference being that the receivers and not the senders request the immediate propagation.

How would you handle my use case — to fetch information at the immediate time that a morning digest is being sent out, to ensure it is as current as possible?

Maybe there is still a use-case for true pull semantics, to allow you to set the schedule at the end of your pipeline, and then the upstream agents would propagate?

Admittedly I am very new to Huginn, so I may be missing something, an perhaps there are easier ways to accomplish what I want...

On Aug 14, 2015, at 7:48, Andrew Cantino notifications@github.com wrote:

Hey @elsurudo, actually this is pull semantics, and I agree it's a bit confusing.

We have a after_create :possibly_propagate in Event, which looks like this:

def possibly_propagate
#immediately schedule agents that want immediate updates
propagate_ids = agent.receivers.where(:propagate_immediately => true).pluck(:id)
Agent.receive!(:only_receivers => propagate_ids) unless propagate_ids.empty?
end
This is actually looking at the creating Agent's receivers and pushing the event to any that have requested immediate propagation.

—
Reply to this email directly or view it on GitHub.

[cantino]

I usually schedule the required agents slightly earlier and allow the events to flow into the dependent agents, but you have a valid use case. There is also the SchedulerAgent for specific control.