But can something be done to prevent users from not being able to open rules? We're talking about the very core of this platform here. Whether that is not allowing us to save a "bad" rule or something else, you have to see this is a significant issue for complex rules that can suddenly no longer be opened.
This is caused by some bug. There is no other answer than that. It has to be found. Obviously we don't want people to be unable to open a rule. And just as obvious, something got in your way. Sometimes database corruption can cause this, and sometimes it's some latent bug. I intend to find out which it is in your case.
It appears that the error was caused by a missing Hub Variable, WindowFansAreSetUp. Could you possibly have deleted that variable? It certainly should not throw an error, but that is what caused it. This will be fixed in the next release.
I hope this will result in a change to prevent users from saving a rule containing a variable that doesn't exist. Why not try to avoid problems in the first place rather than fight with them all later...
Another example of this idea and something else we could all use (I got burned by this twice) are rules that don't run because there's an extra AND for example (i.e. IF X=Y AND B=C AND AND E=F). They can be tricky to spot due to line breaks and there's no rule level indication of broken logic. Anyhow, that's for a different post.
This is beginning to look like database corruption is the original source of the problem, and in turn some unprotected references in RM caused the error. This wouldn't have turned up in most testing, or in other users' use of RM. The unprotected reference should obviously be protected, and that's how I got into the rule. But this particular action became corrupted somehow, and unless you intentionally messed it up (doubtful), that points at the database.
TL;DR: Probably something like WindowFanLastRunDate (global) and CurrentDate (local)
I am trying to find the number of days since the window fans last ran (they are controlled on/off in another rule which updates WindowFanLastRunDate global var).
I believe at one time I had a local var in the dead rule that I would set to the current date (let's call it CurrentDate) and then the rule did math to figure out the number of minutes between the WindowFanLastRunDate and CurrentDate, then converted to days and alert me if >X days.
I recall eventually having a similar setup in other rules so to simplify I created a GlobalCurrentDate global var that all the rules could use instead. It's updated nightly by another rule. Once that was created I would have switched the rules (including this dead one) to use GlobalCurrentDate instead of the local CurrentDate var and then removed the local vars.
The dead rule in question probably have looked alot like this one:
I'm still looking at this, and will hunt down any other possible similar break (from .startsWith()). But, fix won't be in until next week. If you still have that rule then, the fix would allow it to open, and be repaired.
If there's something I can try to avoid in my rules to minimize the potential of this happening again please let me know (using too many variables? renaming variables? mixing local with global? variable math? other?).
I'm still afraid rules will continue to break on me as they have in the past.
Unfortunately that's not very helpful in most cases... if I make changes to 6 rules and then try to open a 7th and it won't open, restoring a backup blows away my other 6 changes. Of course I can export the 6 I changed, restore a backup and then restore the 6 I changed... but you get the idea, this is not good.
I guess you're implying that you don't know what we can try to avoid in order to limit this kind of issue.
Database corruption is rare, but does happen. We see evidence of it here from time to time. Obviously, it can't be predicted, and the only remedy is db restoration. I can't be certain this is what happened to you. What you experienced is rare. What I can do is to further solidify RM with respect to missing rule elements, so that the rule can be opened. It already has means to detect and display broken actions and broken conditions, etc. If you know a rule has a problem like this, and you can open it, fixing it is easy. Often these are UI failures, and the rule continues to run as expected. But, when opened it is corrupted, Every time someone like you reports an error like you hit, we fix it, preventing this particular corruption from ever again preventing access to the rule.
I broke a few rules in my early HE/RM days. I chalked most of it up to getting careless when building some fairly complex actions with parameters, expressions, etc. And not completing the process before clicking "Done." Pretty sure i clicked the browser back button once or twice also. I was pretty frustrated a couple times, for sure. What i ended up doing was just creating a backup before i started creating or editing any rules. Takes an extra minute on the front end, but can save hours of work and frustration on the back end. Now that I've gotten the hang of things, i usually skip that step. If i were to hose things up, I'm usually only working on one project at a time, so restoring the nightly backup is an easy fix.
