To avoid exceeding usage limits of the services we connect to it’d be great if we could rate-limit flows. Something along the lines of “Execute this flow a maximum of X times per Y amount of time”, queueing additional triggers to be processed later.
For bonus points: it’d be great if we could rate-limit individual branches of a flow with some kind of “speedbump” piece. Different branches might connect with different services, therefore have different rate-limiting requirements. With only flow-level rate-limiting all processing would have to be slowed down to the weakest link.
Finally, it’d be super cool if Activepieces could automatically set/suggest a rate-limiting configuration based on the usage limits of the services used in the flow. This would massively improve reliability by default, which is especially great for non-technical users. This would require a non-trivial amount of maintenance though.
This would be a really helpful addition for complex pieces, that cause problems when running all at the same time. (Like the “Max Rows to Poll” functionality that Google Sheets piece used to have)
That’d be an interesting new primitive, though I’m not sure if it’s the right one for this specific purpose.
As far as I know (can’t check right now unfortunately) the schedule piece has a maximum resolution of 5 minutes, which would usually be too slow. For my usecases (and probably @Michael_ES’s too) I need to prevent things going super fast, as in tens/hundreds/thousands of runs per minute, but I’d still like processing to be as fast as reasonably possible.
This kind of “indirect functionality” is also not obvious/challenging for non-technical users. This could probably be solved with good tutorials/documentation, but I’d prefer a simpler solution to begin with.
Finally, in principle every flow should be rate-limited for reliability, things would get very messy if I need separate “trigger → queue” and “queue → actions” flows for everything
