7.0 Alpha 8 seems to break {TRIGGER.VALUE} using trigger expressions

[Linwood]

I had posted this in the help section thinking I was doing something wrong, but I am pretty sure this is a bug.

That thread is here: https://www.zabbix.com/forum/zabbix-...pgrade-mistake

There is some discussion there on my attempts to debug.

But here's the short version. I upgraded from a 6.x version (that started with a 4.x version long ago, and had templates even older). Everything seemed to work but I noticed a LOT fewer alerts, and tracked it down to this.

Here is a screen shot that shows a trigger for a device which is down (the pingCheck is an external check doing pings, long story, but please accept that its value is zero, the device has not been plugged in).



The first is how the triggers in many templates I have (which pre-date recovery expressions) work, it is a combination expression where the expression to use is picked by {TRIGGER.VALUE}. It should be in PROBLEM state.

The second shows that it goes to problem when it is converted to a recovery expression.

The third line shows it goes into problem if {TRIGGER.VALUE} is removed, and the final shows a more complete test as it converts the three expressions into two with an AND to show that the recovery portion ({TRIGGER.VALUE}=1) is also true, not just being carried along by the OR.

I am not good at reading debug logs (in particular assuring I have the right line to go with any trigger), but I think (emphasis on "think") I caught it in the evaluation here:

578403:20231207:044926.233 evaluate_expression(): ( 0=1 and "{TRIGGER.VALUE}"=0 and 0=0 ) or
( 0=0 and "{TRIGGER.VALUE}"=0 and 0=0 ) or
( "{TRIGGER.VALUE}"=1 and 0=0 ) => 0​

To me that evaluation to zero is incorrect. If TRIGGER.VALUE is 1 the 3nd component of the OR is clearly true, and if TRIGGER.VALUE=0 then the second component is true. A clue may bein the quotation (which is not in my trigger), maybe it is some kind of string vs number comparison? Not sure (and not really sure this debug is actually the right one).

But it sure looks broken.

Is there anything else I can test or try?

Linwood

PS. This is running on a HyperV Ubuntu 22.04, distro installed 7.0 Alpha 8.

PPS. {$EDGE_DEVICE}=0, though all this gives the same answer with 1

[Linwood]

Here is a simplified example. I created an item with a regular (no parameters) ping. The device is down, so it is 0.

When put together as an expression + recovery it gives the right answer (Problem).

When put together with an OR and testing trigger.value it comes out OK.

[Linwood]

I haven't tested it, but the issue was accepted and worked and released recently to flow into the alpha/beta versions upcoming.