Your expression is deeply nested too much?

[Koichi_Tsuji]

Is anyone notice to see the error when you "relatively" heavy/expensive expression into Appsheet?

The expression is not too heavy from our prospective, used to be cleared by AppSheet expression parser before. However, once we pushed the expression which is little expensive ones (ones for Select expression with in/contains conditions) then I see the error. Your expression is deeply nested and App is not runnable.

I suspect Appsheet team made changes or something for expression parser, otherwise such error can no be explained.

@takuya_miyai 

@Steve 

[WillowMobileSys]

I have been seeing the message below once the expression reached a certain size.  It never goes away - even after editing.

[Koichi_Tsuji]

Error message itself is not exactly the same as mine, but I suspect it shares the same root causes.....

[MultiTech]

This is actually something that's been there for years, but most recently, within the past month or so, it seems this has been tied down a bit more.

Generally speaking though, when you encounter this error you can still move forward. You just have to get the formula into a green state, and then add on the extra bits that push it beyond its limits.

As long as it started in a green state, the system should accept it and it will actually work - even though you're getting this error. As long as the formula that you're putting into that field is correct, so that there's no errors that will be found, you can keep modifying and adding things to that formula - and it will continue to work. 

But once you let the system reevaluate things, and it actually finds an error, it will never get back to a green state again. At that point the solution is to simplify your formula so you can get back to a green state, then add in all of your extra bits on top - putting it back where it belongs.

------------------------------------

I've got one app that's been inside this zone for a while now: my giant note parameter creating formula, in the app that I made to make all the template table stuff that I have for my patreon supporters.  It's something like 200 or 300 lines... 🙄

But as long as I keep making modifications to the formula that I know are 100% correct, it has allowed me to continue to make updates to that formula - with everything working exactly as it should, even though I have that error saying that the formula is too big to evaluate.

It's all about staying in a green state, you just can't ever save an error - when the system is reloading after the save, that formula will be reevaluated, even though the system says it's too big, and the error will be found and then you're screwed.

As long as your giant formula is always 100% correct, you shouldn't have any problems. 💪

[Steve]

Escalated.

[Steve]

Can you provide the/an expression that appears to trigger this error? The developers would like to consider it. Feel free to DM me if concerned about sharing it here.

[Koichi_Tsuji]

Thank you @Steve  I will DM to you later today.

[Koichi_Tsuji]

For those who may see this thread, this is the exact error message we see, which you may see as well.

[preethamm]

@Koichi_Tsuji Your example reduces to 
Table[SeqCol] = MAX(SELECT(Table[SeqCol],[_RowNumber]<[_THISROW].[_RowNumber]))

This self-refernce causes an infinite loop since SELECT tries compute the same column. We used to timeout before and now the nesting check stops at this at some deeper level. Afaik, apart from the nesting change, nothing has changed in the evaluation for a while. I removed the nesting check and the app load timed out. Sequence number generation has in general never worked reliably (and hence not supported). 

We should have ideally warned this in the editor itself. However, our self-reference checks are intentionally not restrictive enough to catch this. I have added a TODO to fix this.

[Steve]

Thanks for the DM. I've passed it along to the development team.