Hi there!
My question to anyone that may know, specially any Codans out there. I have a formula in a button, that is performing some actions.
It’s throwing this error message. Is there any way to know what is the invalid action that it is unable to perform? Because it doesn’t provide additional information to debug, and as far as I see, the 49 rows that the button is supposed to create do get created.
(I mean, if there is a way to enable some developer debugging features to be able to track down problems, not necessarily asking for help with this particular formula)
2 Likes
As far as I know there are not many options for debugging.
The only for sure thing is that up to (including) the code that created the new rows, your code is correct. From there on, commenting out parts of your code until you find the code that throws the error is the only way to debug.
In case you didn’t know: commenting out can be done with “//” for a single line of code (up to a linebreak) or "/* " CFL code “*/” for complete sections. (don’t use the " in your code).
When commenting out sections of code, don’t forget to comment out the comma at the end of a section (if there is one of course).
1 Like
Thanks for your reply! It sucks that there is no proper way to get more feedback when errors happen.
In this case it was particularly tricky because it was a single action to create some rows, that were in fact being created, so it made no sense to display an error message.
I eventually found by putting each little element within the formula in other columns, to test each step, that there was a “phantom cross-doc row” that no longer existed that was finding it’s way into the input list for the button, thus creating “unable to perform invalid action”.
Yeah I struggled with this just today myself actually, just deleting one parameter at a time in a RunActions formula to find the culprit, definitely room for improvement here
1 Like
For complex formulas I have gone as far as creating a debug table that I add messages to from that complex formula eg. … debug.addrow(“Message column”, “Message”)
This enables me to track what parts of a formula got completed, and especially track the logic flow if there are complex or nested If/SwitchIf statements etc.
For complex formulas I also find it useful to move some of the formula into another button, especially for long stretches of similar code, such as in a SwitchIf where say each case in the SwitchIf adds a row to a table, potentially different tables. I find that can clutter a complex formula and creating separate buttons (a-la “functions”) helps keep the formula easier to read.
This can also help the speed of editing a complex formula as I find the formula editor can slow down significantly as it constantly re-evaluates the entire formula as changes are made … so moving parts of the formula to other buttons helps a lot with this.
I have not done any testing on this approach for performance impact, but it hasn’t seemed to be an issue for my docs. I’d love to hear if anyone has thoughts on this from a performance perspective.
2 Likes
Thanks, @Rohan_Mitchell, for the tip on the debug table! 
Great idea. It’s really a shame that Coda doesn’t have a proper debugging feature, not even a console. I’ve realized that I spend a lot of time debugging Coda formulas. The language itself is quite nice—easy to write but tricky to debug. The more experience I get with Coda, the less fun it becomes, except for doing simple or classical tasks. Coda is really nice but the platform is not tailored for advanced formulaes. At least is is frustrating to spend a lot of time without proper debug means.
1 Like
Cool! Thanks for the advice!
I have done the “split formula into different buttons” before precisely because of the reason you’ve mentioned: unbearably slow editor. It can get to a point where you have to wait like 10 seconds for each keystroke.
Usually when everything is fully built I copy paste it into one button to optimize, and hope I never have to edit it again lol
