For background, I had a Perspective view that was previously set up with a somewhat complex binding structure that involved, at one point in the transform chain, a tag() expression function. I noticed the “Flood limit tripped, starting 5000ms cooldown.” error popping up because of that.
I had previously seen the “Flood limit tripped, starting 5000ms cooldown.” error in another view, and removing the offending tag() expression function seemed to fix it completely.
However, this “Flood limit tripped, starting 5000ms cooldown.” just will not go away no matter what I try.
Things I’ve tried:
Removing the tag() expression function from any bindings.
Removing the binding on the property entirely.
Deleting the view entirely.
Replacing the path in an Embedded View component, which lead to this now-nonexistent view, with a different one as a placeholder.
Restarting the gateway, and the computer the gateway runs on, multiple times.
Removing every single project from the data/projects directory and restoring them (without replacing the view that was causing the error.)
So this view should not even exist, at all, according to the gateway, but it is still throwing this error with that view’s property as the apparent culprit.
Regardless of what I do, this error floods the logs whenever the view where it originally occurred is loaded. The view no longer exists, but the “Flood limit tripped, starting 5000ms cooldown.” error in the log is reporting that the property in this non-existent view is causing it.
Frankly, I’m stumped. I have no idea how to even begin to reproduce this behavior, otherwise I would’ve tried to write a better report with reproduction steps included.
Well, in classic style for my forum posts: I’ve managed to fix it like 20 minutes after creating the post, but I’m still dumbfounded by what could’ve caused this to happen.
Upon closer inspection of the perspective component tree, I noticed an arrow next to the embedded view component. When expanded, the embedded view showed the following:
The Label and MoreValues components are exactly what exist within the view that the embedded view is referencing. I have no idea why they began to show up in this way. It’s almost as if the embedded view had become a container? I legitimately did not think it was possible for an embedded view to show up in the tree this way.
Removing this “glitched out” embedded view and adding a fresh one solved the problem.
I do have a gateway backup in this state. Is there a way I can send it that’s better than just posting on the forum? I don’t particularly want to post this gateway backup here, even if it does get removed immediately after being downloaded.
Best way is to send it in to support (reference this thread; the reps can contact me if they have questions). Failing that, forum direct messages or emails (my forum username @ inductiveautomation.com) also work.
To clarify - this is an entirely legitimate error, and in the vast majority of circumstances indicates a circular binding issue.
@md.szyman ran into a very weird issue where components became nested inside each other in a way that shouldn't be possible to do through the designer. Are you specifically getting the flood limit error, or do you also have nested components in an embedded view?
Another thing that I’ve found causes this error is use of the tag() Expression function within Perspective.
The solution for me is usually to change the binding setup around so instead of having a single property with tag(), I have one property that represents the path to the tag I want, and then another property which is an indirect tag binding based on that path property.
We are getting the flood limit error on a component that has the tag() function in a transform expression.
There is no nesting going on. Simply label displays on a column view. Is there a known bug with using the tag() function in perspective that causes the flood limit tripped error?
got this a lot also with an Expression to a props with partial tag path, then a transform expression with 2 tag() in it.
I finally use Tag Binding Indirect, read the tags in custom props, then do what I need with the tags value
Can someone help me with instructions on how to find the source of the flood limit trip log? We are getting them constantly, problem is we have many projects and many views that could be the source of the problem.
This can mean bindings are being triggered in a recursive or circular pattern. That is, one binding references a second, which references a third, which itself references the first. Or something like that.
Or you simply have very many bindings that are changing (due to tag updates or other external reasons) and your gateway doesn’t have the horsepower to keep up.
First thing, like in other case, check for now(some_value). If some_value is greater than 0 (zero update only once) and smaller than 1000 check what is executed.
The other option is mainly circular reference. Ignition will detect simple cases, but not complex ones. Doing smaller bindings in custom props can reduce the load, and make it easier to identify issues
