[Timeline] Flow disabled because it runs 60 times

[Jero]

Are you sure all the action cards exit properly? As in a test will always result in a done state. You can also test this with an all card after all actions for true/false and maybe log something to the timeline.

I did find one bug in the disabling logic which will cause all triggers after disable to instantly hit the limit again. I would expect duplicating this Advanced Flow will fix your problem for now until a proper fix is live.

However I still dont understand how you hit the limit in the first place because that logic should work fine.

[Jero]

@Jero

I did find one bug in the disabling logic which will cause all triggers after disable to instantly hit the limit again. I would expect duplicating this Advanced Flow will fix your problem for now until a proper fix is live.

This will only happen if some card never exits btw.

[homeypro]

Hi @Jero,

The output of this script is always:

So that can’t be the problem right?

[Jero]

Does right click → test from here also finish the card?

[Undertaker]

Try the new firmware. The error seems to have been eliminated.

[Picsou621]

Perhaps the error has been corrected, but it is not apparent from the corrections mentioned here…

[Peter_Kawa]

It happens here recently. Firmware v8.0.6

Can’t pinpoint it, but it only appears to happen after test runs (right-click “run flow from here” command). However, it’s only this flow.
Timeline always gets ‘rate limited’ as well when ‘testing’ flow parts.

@Jero Is it possible Homey is running over 60 instances of the flow?
While it doesn’t say: “it was started or triggered 60 times whithin X seconds/minutes/hours”…
Or is it a translation thingy? It’s a pretty ‘vague’ description to me.

Flow:

.
It’s “solved like this”, but …

[Peter_Kawa]

Just after a soft reboot:

These are flows with “Every x time unit” triggercards

Shortest time intervals:

• flow AF Homey … : every 31s
• flow Time_ … : every 10s
• flow Show …: every 60minutes
  But it has a loop every 28 seconds

[robertklep]

Another day, another rate limiter bug

[Peter_Kawa]

Well, keeps us busy , and it’s better than SSDD

[Jero]

It means the code thats runs the Flow did not exit properly. The code looks something like this:

count++;

try {
  const result = await this.run(args);
  return result;
} catch (error) {
  throw error;
} finally {
 // This block always executes.
  count--;
}

This can be triggered easily if you have a Flow that triggers every second that starts a delay for 120 seconds for example. On the 61th time the previous executions are not done yet so to prevent this ‘leak’ going on forever we disable the Flow.

I have a feeling the system might be triggering your time cards alot of times on reboot so maybe you can try to log if that is happening?

It can also be a bug in this count code but I would expect alot more reports if that were true.

[Peter_Kawa]

Hi Jeroen,

Thanks for looking in to this.
I could reproduce it with two flows today. I created a counter and a log for the shortest Every X s triggers in both flows and restarted Homey.

Do you have an idea why it does not occur anymore when I just enable the flows again? It happens only after restarts.

1. Part of flow AF Homey insights monitor
   (I can’t imagine this takes longer than 31s to finish. How would I log that?)
   
   

• 1a) Logged with Papertrails:
  (Just one entry and 1 counted, which is weird (flow supposed to be disabled at 14:54)
  2022-09-17 14:47.04.373 31s trg count#: 1[flow AF Homey insights monitor]

2. Part of flow AF Time_Date_stuff
   
   

• 2a) Logged with Papertrails:
  (This also stops at 14:47 and did not reach 60 times)

2022-09-17 14:41.50.257		10s trg count#: 1 [flow AF Time_Date_stuff]
2022-09-17 14:42.01.222		10s trg count#: 2 [flow AF Time_Date_stuff]
2022-09-17 14:42.10.283		10s trg count#: 3 [flow AF Time_Date_stuff]
2022-09-17 14:42.20.266		10s trg count#: 4 [flow AF Time_Date_stuff]
2022-09-17 14:42.30.339		10s trg count#: 5 [flow AF Time_Date_stuff]
2022-09-17 14:42.40.258		10s trg count#: 6 [flow AF Time_Date_stuff]
2022-09-17 14:42.50.287		10s trg count#: 7 [flow AF Time_Date_stuff]
2022-09-17 14:43.00.412		10s trg count#: 8 [flow AF Time_Date_stuff]
2022-09-17 14:43.10.397		10s trg count#: 9 [flow AF Time_Date_stuff]
2022-09-17 14:43.20.262		10s trg count#: 10 [flow AF Time_Date_stuff]
2022-09-17 14:43.30.302		10s trg count#: 11 [flow AF Time_Date_stuff]
2022-09-17 14:43.40.456		10s trg count#: 12 [flow AF Time_Date_stuff]
2022-09-17 14:43.50.484		10s trg count#: 13 [flow AF Time_Date_stuff]
2022-09-17 14:44.00.569		10s trg count#: 14 [flow AF Time_Date_stuff]
2022-09-17 14:44.10.368		10s trg count#: 15 [flow AF Time_Date_stuff]
2022-09-17 14:44.20.560		10s trg count#: 16 [flow AF Time_Date_stuff]
2022-09-17 14:44.30.498		10s trg count#: 17 [flow AF Time_Date_stuff]
2022-09-17 14:44.40.439		10s trg count#: 18 [flow AF Time_Date_stuff]
2022-09-17 14:44.50.499		10s trg count#: 19 [flow AF Time_Date_stuff]
2022-09-17 14:45.00.882		10s trg count#: 20 [flow AF Time_Date_stuff]
2022-09-17 14:45.10.396		10s trg count#: 21 [flow AF Time_Date_stuff]
2022-09-17 14:45.20.467		10s trg count#: 22 [flow AF Time_Date_stuff]
2022-09-17 14:45.30.373		10s trg count#: 23 [flow AF Time_Date_stuff]
2022-09-17 14:45.40.542		10s trg count#: 24 [flow AF Time_Date_stuff]
2022-09-17 14:45.50.526		10s trg count#: 25 [flow AF Time_Date_stuff]
2022-09-17 14:46.00.619		10s trg count#: 26 [flow AF Time_Date_stuff]
2022-09-17 14:46.10.441		10s trg count#: 27 [flow AF Time_Date_stuff]
2022-09-17 14:46.20.633		10s trg count#: 28 [flow AF Time_Date_stuff]
2022-09-17 14:46.30.503		10s trg count#: 29 [flow AF Time_Date_stuff]
2022-09-17 14:46.40.468		10s trg count#: 30 [flow AF Time_Date_stuff]
2022-09-17 14:46.50.549		10s trg count#: 31 [flow AF Time_Date_stuff]
2022-09-17 14:47.00.673		10s trg count#: 32 [flow AF Time_Date_stuff]
2022-09-17 14:47.10.437		10s trg count#: 33 [flow AF Time_Date_stuff]
2022-09-17 14:47.20.516		10s trg count#: 34 [flow AF Time_Date_stuff]

• • When I look at the device tile, it seems to be updated within the triggertime of 10s;
    Device screenvid:
    

.
Second Test
Just now I tested with the counter and log directly connected to the “suspect” triggercards;
As I expected a bit, there were no issues now, after restarting Homey

So, I changed some time triggers and increased the time with a few secs, and I’vd changed the delays with a few secs as well.

After a reboot, all’s OK.
But, it still puzzles me why 31s is too short for the flow 1. part to finish

I’m thinking to create separate AF flows for <60s time triggers.

[Peter_Kawa]

mmzzz Today it popped up again, the three flows wer disabled again. It was after a power failure this morning.

If i’m the only one with this problem, I’ll workaround it like this:

[Jero]

What do you mean by power failure?

[Peter_Kawa]

The mains power in the house was cut off for a while
The odd thing is, once the flows are enabled again, after the 60 times error, it runs fine

2022-09-18 15:07.39.901		31s trg count#: 890[flow AF Homey insights monitor]
2022-09-18 15:07.48.103		10s trg count#: 3986 [flow AF Time_Date_stuff]
2022-09-18 15:08.00.452		10s trg count#: 3987 [flow AF Time_Date_stuff]
2022-09-18 15:08.12.055		10s trg count#: 3988 [flow AF Time_Date_stuff]
2022-09-18 15:08.24.341		10s trg count#: 3989 [flow AF Time_Date_stuff]
2022-09-18 15:08.36.055		10s trg count#: 3990 [flow AF Time_Date_stuff]
2022-09-18 15:08.37.335		31s trg count#: 891[flow AF Homey insights monitor]
2022-09-18 15:08.48.059		10s trg count#: 3991 [flow AF Time_Date_stuff]
2022-09-18 15:09.00.251		10s trg count#: 3992 [flow AF Time_Date_stuff]
2022-09-18 15:09.12.047		10s trg count#: 3993 [flow AF Time_Date_stuff]
2022-09-18 15:09.24.081		10s trg count#: 3994 [flow AF Time_Date_stuff]

[Vincent_Vans]

Hi All. I have the same issue. Reported it to Athom in August. To my suprise, they acknowledged the problem (reports from multiple users), the ticket was closed because they said they could not reproduce the problem.

I also provided more info (it always occurs directly after a nightly reboot) and a diacnostic report. They did not seen keen to solve this issue.

Their advice was to stop using Advanced flows, and go back to normal flows. Right…

I have been a Homey user from the beginning, but after several issues like this (hence the nightly reboots), my sympathy for this startup has dropped to zero… But now I understand why the Homey core and app are stll full of tiny bugs and development seems to have stopped: users just stop reporting when nothing is done with their feedback. At least I have reached the point that I am not putting any more energy in it.

My compliments go out to all the users on this forum, always willing to help. I will try the workaround mentioned above, thanks Peter_Kawa.

And thank you all for letting me blowing off steam

[Undertaker]

The next time it happens to me, I’ll send Athom a screenshot. However, it is noticeable that only advanced flows have this error with me. I can confirm that this phenomenon occurs sporadically after a restart.

[Arie_J_Godschalk]

Yeah ,same for me, a few days back when restarting Homey myself normally.
Also contacted Athom about it (a followup from before) and informed them as best i could.

And indeed, only Advanced Flows with a Start every X Minutes, seems to get disabled on restart.

[Peter_Kawa]

@Vincent_Vans

hence the nightly reboots

Odd, I pretty much never restart Homey, unless after a power cut, or as a cause of a firmware update.

[fantross]

+1