To test this scenario:

• Define item
• Define trigger with expression of "item.nodata(300)=0" and recovery expression of "item.nodata(300)=1"
• Use zabbix_sender to send item data with a timestamp of 600 seconds ago (ie zabbix_sender -z zabbix-server -i ./zabbix_item_data.txt -T) ---- TRIGGER WILL NOT ENTER A PROBLEM STATE
• Use zabbix_sender to send item data with a timestamp of 100 seconds ago (ie zabbix_sender -z zabbix-server -i ./zabbix_item_data.txt -T) ---- TRIGGER WILL ENTER A PROBLEM STATE AND THEN RECOVER IN 200 SECONDS

If you have issues with Zabbix proxies / Zabbix agents / Zabbix Sender where the data is delayed this will effect your nodata() triggers.

The actual impacts to us was that we received some old data (snmptrap) that would have actually has the trigger enter a problem state and resulted in an action; however as a result the trigger did not enter a problem state and we missed the event.

Its almost like there needs to be a trigger function that returns the items submission time in epochtime ie the equivalent of item.now(); then you could do a trigger like:

• expression - item.nodata(300)=0 or (item.now() - item.submissiontime() > 300)
• recovery expression - item.nodata(300)=1

The above would cause the trigger to initially fire regardless and then in the next evaluation recover.