Rule Machine 4: Exception when editing triggers

[trebor]

Was having an issue with only some time triggers actually firing. Edited one of the non-firing triggers to slightly change the time. Now attempts to edit triggers generate an exception:

java.lang.ClassCastException: java.lang.Integer cannot be cast to java.lang.String on line 647 (selectTriggers)

Doing it again just displays a blank triggers list with no editing options, and a slightly different exception:

java.lang.ClassCastException: null (selectTriggers)

Rule Machine 4 : Multiple Time Triggers not working has more info

I made a copy of the "bad" database and restored to yesterday's backup. This allowed me to get back into the triggers list and delete all of the triggers. I replaced them with an "every 5 minutes" trigger.

At this point, the rule is not firing at all, despite the new trigger! I checked the status page for the rule and it shows 3 scheduled jobs, all for some of the now-deleted triggers.

I tried pausing/unpausing the rule, this does not seem to have reset anything - still 3 scheduled jobs. I also rebooted the hubitat, no apparent change.

[trebor]

More info.

Cloned the rule, then deleted it. Renamed the cloned rule to use the original name. The periodic trigger on the cloned rule fired as expected (as opposed to the original [now deleted] rule, where it didn't)

Went into another rule that invoked the original (now deleted) rule. The action that invoked the deleted rule was no longer displayed. Attempted to enter the action editor, and got:

java.lang.NullPointerException: Cannot invoke method tokenize() on null object on line 2266 (selectActions)

This was a simple rule with only a couple of actions, so I deleted and recreated it, then rebooted. System appears to now be in a stable state where the rule is getting triggered every 5 minutes.
I have backups at various points in the process.

[bravenel]

Could you tell me what the nature of the reference was in the rule that invoked the deleted rule? I'd like to track down that error.

[trebor]

I had two rules, DayTypes and Peak. Peak was the misbehaving rule that I cloned and then deleted.

I had another rule, Reboot, that had a Location event: SystemStart trigger and two separate actions, Run Actions: DayTypes and Run Actions: Peak (not a single Run Actions that fired both actions, because at the time I created it I wasn't sure if this would guarantee the desired order of operations).

If memory serves, after the clone and delete, the list of actions only showed the Run Actions: DayTypes action, but entering the action editor caused the exception.

I have lzf archives of the state before and after this sequence of operations if it helps. Available on request.

[bravenel]

@trebor

after the clone and delete, the list of actions only showed the Run Actions: DayTypes action, but entering the action editor caused the exception.

OK, great, thanks.

[trebor]

Found a very interesting anomaly that may give you insight into what is causing this.

I decided to tweak the actions for the rule with the misbehaving trigger. After doing so, just on a whim, I tried to edit the triggers -- and the editor displayed correctly this time! I backed out of the trigger enter and re-entered it -- and the editor threw an exception as before.

Aha, says I, something in the action editor is temporarily fixing things enough to get into the trigger editor. So I go hunting for a replication case, and found one.

I can repeatably do the following:

Invoke actions editor.

Add a simple conditional action (to end of list). Curiously, this does not let me set a condition, it defaults it to FALSE and proceeds to ask me what action to select. I choose Log message "derf" since it's a harmless action.

Click done with actions.

Immediately click on the triggers list to access the triggers editor. This displays the triggers instead of throwing the exception. However, it doesn't display the list of triggers with options to add/delete and so it. Instead it displays the editing page for the first (only) trigger in the list. In other words, it's one layer deeper than it should be.

If I then back out and reclick on the triggers list, the exception is thrown.

If I don't back out, I can edit the trigger but there is no cancel trigger button.

I edit the trigger, click done with trigger, and we're back to the java.lang.ClassCastException: null (selectTriggers) exception situation. The edit to the trigger is retained.

In addition, another way to replicate this is to simply create a new backup and then immediately restore it. If you do so, you can select the rule, click on the trigger list and you will immediately go to editing the first trigger (bypassing the main trigger editor page), but as soon as you finish editing that trigger, you're back to generating the exception.

[bravenel]

@trebor

Invoke actions editor.

Add a simple conditional action (to end of list). Curiously, this does not let me set a condition, it defaults it to FALSE and proceeds to ask me what action to select. I choose Log message "derf" since it's a harmless action.

Click done with actions.

This isn't right, and I cannot reproduce it. Please show screenshots of each step. It almost seems as if you have some database corruption going on, as these are not the normal things that happen with Rule 4.0.

Please start with a new rule, and reproduce these steps. It should indeed be asking for a condition for Simple Conditional action.

@trebor

In addition, another way to replicate this is to simply create a new backup and then immediately restore it. If you do so, you can select the rule, click on the trigger list and you will immediately go to editing the first trigger (bypassing the main trigger editor page), but as soon as you finish editing that trigger, you're back to generating the exception.

This sounds as though you are backing up the problem and restoring it back.

[trebor]

@bravenel

This sounds as though you are backing up the problem and restoring it back.

No. This is not the case. It was impossible to get anything but the blank screen and exception when invoking the trigger editor under normal circumstances. However, either a save/restore backup or adding a conditional action changes the behavior, and allows one-time partial access to the trigger editor.

I did greps of the text on the gear page of the rule before the save, after the restore, and after the one-time access, and it isn't changing. So the change in behavior is likely related to some global state.

Furthermore, the issue with the simple conditional action seems to be limited to the misbehaving rule; simple conditionals in another test script in another tab can be created correctly.

I have made several attempts to find a replication case that causes this behavior to occur in a different script. I got it to happen once but I was doing a lot of different things (messing around with the misbehaving rule in a different tab) and wasn't specifically checking for that situation. And like an idiot, I forgot to save a backup with two misbehaving scripts.

What I have done is make a video showing the change in behavior: Dropbox - Hubitat.mov - Simplify your life

The saved backup that is used in the video is here: Dropbox - Temp fix replication case.lzf - Simplify your life

[bravenel]

OK, so you have a corrupted rule that you cannot replicate the failure of, right? If so, forget it and delete the rule. There is no way to figure out how it got corrupted, or why. The only thing that would be of use is a replicable failure of a newly created rule.

[trebor]

It would be helpful if you could examine the backup and determine more about the nature of the corruption. I am more than happy to experiment to try and find a replication case, but any information you can provide about potential areas to experiment with would be useful.

This corruption was clearly caused by a bug in the editor (if it is a corruption; it may well be that the rule is syntactically and semantically correct but, once created by the editor, a bug in the editor renders it non-editable).

Since there are no public tools available to examine the contents of a backup, I am flying blind. But you are not. You know, for example, what potential issues are implied by the "java.lang.ClassCastException: java.lang.Integer cannot be cast to java.lang.String on line 620 (selectTriggers)" exception because you have the source code.

If you can narrow down the scope of potential problems, then I am willing to invest in a little grunt-work to try and get you a replication case. But if you are not willing to do this, then I might as well leave well enough alone; I can, with the current buggy functionality, get the rule into a state where it does what I need it to do.

But that does not help you, which has been the entire point of this thread from my perspective.

[bravenel]

@trebor

It would be helpful if you could examine the backup and determine more about the nature of the corruption.

This isn't possible. Neither does knowing the line of code shed any light on the issue. The only way to analyze this sort of failure is with a repeatable failure.

I appreciate your interest in helping us track down the problem. But, I can't reproduce it and neither can you, so where does that leave us? With a mystery.