Multiple entries for Automation Rule scripts is a problem

I see you have tweaked how script actions are processed for Rule automations, but it is causing a new problem.

When there are more than 50 entities selected by the Rule filter, the Rule’s actions are invoked multiple times with max 50 entities passed to the script in args.currentEntities on each invocation.

I have some scripts which expect to only be invoked ONCE per hour, and now they get invoked many times, depending on how many entities the Rule filter matches.

In this particular case there is no simple way for me to limit the filter to match just one entity, which is all I need, because this script actually ignores args.currentEntities and uses 'fibery.entity/query' instead.

In this case it would be useful to have a way to ensure the script is invoked only once; maybe the ability to specify “maximum number of entities” for a Rule to match? As it works now, it is inefficient use of your server resources, or it requires that I move the Rule to a different Space where it is easier for me to limit the Rule’s filter to match only one/few entities.

Hi, @Matt_Blais

We didn’t tweak script action recently. It always work in the described way due to memory limitation of script engine.

Thanks,
Oleg

1 Like

Well it didn’t work always like that. Before the spring 2023 we executed script once per each entity. So if rule was triggered for 1000 entities, script would be executed 1000 times. This was not sustainable so we went with batched approach. Anyway we never called script with all the entities due to engine memory limitations, just like Oleg says.

to only be invoked ONCE per hour

To implement this correctly you need some external storage (some Fibery Db maybe, or your own one) where you will store last script execution time. And you will exit immediately if hour has not passed. I don’t see other way to have such guarantees.

2 Likes

Perhaps you could add a new Filter to allow specifying LIMIT/max entities to match?

I get the idea.
This is first request like that and it requires proper design and implementation. And design is more crucial here imho, as most of time users don’t need such limits. So no promises from our side. We will add an Insight and start collecting feedback though.

1 Like

Thanks.

Meanwhile I will work around this issue by moving this type of automation to a dedicated Space where I can control the matched entities, since it doesn’t really matter what Space it exists in.