Steps to reproduce:

1. Create a host and add macro {$SYSTEM.FUZZYTIME.MAX} with value 60.

1. Create the item with unit «unixtime», for example check date and time from database.

1. Create the trigger with function fuzzytime() and macro - fuzzytime({$SYSTEM.FUZZYTIME.MAX})=0

1. Get the first successful value without problems.

1. Simulate a problem with an item, such as changing the password to connect to the database. Put an item in an unsupported state.

1. Waiting for the next item check and changing of the item to an unsupported state.

1. Item changed in unsupported state. The trigger did not go into an unsupported state. And created a problem in the "Problems".

Result:

The trigger did not go into an unsupported state. And created a problem in the Problems. This creates false problems with incorrect date and time.

Trigger will change to unsupported state after second unsupported check.

Recovering of the trigger from an unsupported state also occurs after the second successful acquisition of the value.

Screenshots from the frontend and logs with debug level 5 from Zabbix server in attachments in archives (all IP addresses and credentials in screenshots and logs is hided.)

Expected:

A trigger must immediately be changing to an unsupported state after the item transitions to an unsupported state. This worked including version 5.0.11. The documentation does not describe that this feature works in unsupported state.

This fact has been verified on test benches Zabbix Server 5.0.11 and 5.0.12 in the following environments:

• Debian 10.9
• PostgreSQL 12.7 (Debian 12.7-1.pgdg100+1) on x86_64-pc-linux-gnu, compiled by gcc (Debian 8.3.0-6) 8.3.0, 64-bit
• TimescaleDB 2.3.0

I will be glad if you confirm this problem and it will be fixed in the nearest releases