I have a formula to modify all checkbox columns in a table to true(). The automation fails saying The Automation Result is Too Large.
However, when I run the same formula in a button, it modifies all the rows.
I tried creating an automation to push the canvas button, but that results in the same error message. Aside from creating some modulus hack, is there a way to get this to work straightforward?
Hi @Johg_Ananda ,
I ran into this same issue last week. The problem is:
- ModifyRows() returns a list of all modified rows, and that gets returned into the Result of the Action step in your automation.
- However there is a hard, rather low limit to the size of a list supported by Automation Action results (and presumably conditions as well).
In my case, the action was trying to return 290 rows.
I tried to work around it with a variety of hackery, like wrapping the ModifyRows inside of another action, but wasnât able to get anything to compute the way I wanted it to, sometimes because of obscure optimizations. You might be able to get something to work that way.
Note that I tried RunActions, but accumulates lists from each action step, so you cannot use it to split the processing into multiple partial passes.
I ended up resolving it by revisiting my overall approach to modify fewer rows. In your case, I would recommend trying to split up the modifications of the checkbox into several passes. E.g. maybe only modifying 100 rows at a time and running it multiple times either as separate automations or separate button press actions in the automation.
Support was helping me with this, they said they have this issue on their radar and aim to alleviate this in the future.
2 Likes
Oh and another note - the automation does succeed I think mostly, it just fails at the result step. I suspect your button actually ran correctly, but TBH I didnât spend time confirming that.
1 Like
Ah ok so itâs working but it throws an error? I didnât check the results rather I see the failed notification everyday. Good point @Ed_Liveikis
Well I believe the button runs, runs the ModifyRows successfully, button action completes, but then the Automation throws the error on the result. So I would expect that the button action should have done its thing properly. But the error messages are super annoying so I suggest breaking your action into multiple actions or running the automation more frequently on subsets of the table to avoid the bug.
@Ed_Liveikis yeah I know how to hack around this - but it would be nice if a @Codan would give us some guidance.
When I chatted with support they mentioned it is a known issue they would like to address, but the only way to make the error go away at the moment is to make the button return fewer results, somehow.
1 Like
Did they tell you what the limits are // how to design the hack? Is it the qty of rows?
They didnât tell me the limit. It is somewhere close to but less than 290, because the automation I was running was not previously throwing errors until my table got bigger and bigger, and I first debugged it when we were at 290 rows.
Yes the workaround is to lower the number of rows in the result of the action. So for example if your button is modifying all the rows of a table, you could create several buttons, and have each button do 100 rows, and then do multiple separate actions in your automation, each one which presses a button once.
Button 1:
_userLog.Splice(1,100).ModifyRows(...)
Button 2:
_userLog.Splice(100,200).ModifyRows(...)
âŚetc. This is just one example, I canât really recommend an ideal workaround without knowing your table and formula goals. Note the above solution could have errors if rows are added or deleted in the short period of time between when button 1 and 2 run.
In my case my workaround was to filter and only update new rows instead of the whole table.
1 Like
@Federico.Stefanato @BenLee hey can we get a Codan response here? If automations are âbreakingâ at 300+ rows, and that it is hard to diagnose due to the error message, this is going to create lots of error notifications and frustrations. It would be nice to get some guidance here as to whether we have to go in and split up ea automation like this. Thanks!
2 Likes
There are a couple things about this issue that make it tough to give direction on.
First, itâs really difficult to say what the limit is because that depends on many factors. Itâs like asking you âhow many bags can you carryâ. Bags can be different sizes and may or may not be filled, and what things are in them when the question is asked.
Second, there are many issues to consider that make this a tough problem to solve, like collaborative editing. If an automation kicks off and takes some time to run, but people are editing the doc, and the same fields in particular, how do we juggle which edits take precedence? We have complex algorithms to sort through this, but at the moment it requires some caching as edits are made.
For your setup, Iâm curious if a column button would work to set the checkbox as true. We donât have the same concerns for added doc weight that we used to with the buttons enhancements weâve rolled out earlier this year, so it might be worth trying. Iâd be curious if it works better for you since it looked like you were editing over 2,000 rows at a time.
2 Likes
@BenLee I donât understand how your response fits into the 'button works, automation doesnât. How does that have anything to do will collaborative editing?
If it was âbreakingâ at 30,000 rows ⌠but 300 is a small table for any doc that gets use.