- I need some help here, I was testing a scenario that starts with a webhook trigger from baserow every time I changes a record in the table Manuals. After that it performs several operations.
I activated the scenario and went and make a change in the intended row in baserow, and that triggered the scenario, it ran well, as expected with 39 operations executed.
I kept working on the scenario, and when I was going to test it again, it failed because I didn’t have any more operations. The beautiful thing is that my month started couple days ago and I had almost 10,000 operations available, before that test.
Checking the scenario history I found out that it kept running the same scenario every second or two until it consumed more than 10,000 operations.
I am in shock, has anybody experience something like this, I am getting scare of using Make.com with baserow.
Is there anything I can do to recover my operations. And to know why this happened?
It started at 14:30:24 and finished 14:35:25.
In the previous image you can see that it was ran every second, I cannot do that manually.
Every single call triggered the webhook with the same record modified and it only returned one bundle. It ran 39 operations which is correct.
It asked me to use the old data, and I answer to wait for new data.
Please, can anybody help me with this. I will appreciate it.
Welcome to the Make community.
Looks like the scenario has a Update a Row, and because a row was updated, Baserow sent another webhook request to your Custom Webhook trigger, which triggered your scenario a second time.
This ran in an endless loop that used 10k operations in less than 5 minutes.
To prevent this, this scenario should not be updating any rows in your Baserow because it will cause a recursion. The second module is the culprit.
The second module caused a linear recursion. If that filter did not exist and the last module “Create a row” ran, it could have been an exponential/cascading recursion (one scenario causing another 19 scenario runs of itself, and each of the 19 will cause another 19, etc).
If it were an exponential recursion, it will take less than 30 seconds to use all 10k operations.
To prevent this, never switch on a Custom Webhook scenario until you have tested the final version once manually with the “Run Once” button. If a recursion happens it will be stored in the webhook queue if the scenario is not yet switched on.
2 Likes
Thank you for your help.
This is crazy, I have been working with this kind of scenarios with airtable and nocodb, and never experience this. I guess because in airtable and nocodb the conditions are set in the definition of the webhook not in make.com.
I had tested it several times before turning the scenario On and I didn’t realized it was getting into endless loops.
