Steps to reproduce:

1. Create a host
2. Create a LLD rule with an item type of Zabbix trapper
3. Create two item prototypes with an item type of Zabbix trapper each with a distinct LLD macro (screenshot A)
4. Using the zabbix_sender binary, send only a value for "{#MACRO_ONE}" (screenshot B)
5. Observe an error showing that LLD is trying to create an item with a key of the the itemprototype itself (screenshot C)
6. Note that the real item is still created anyway (screenshot D)

Result:

screenshot A:

screenshot B:

screenshot C:

**

screenshot D:

Expected:

For LLD it appears that each time a discovery JSON is sent LLD expects there to be a value for all LLD macros that are defined in prototypes for that discovery key. But, for trapper discovery this may not always be true. In my environment everything is sent via trapper because the format of the metric data is not something we can send direct to Zabbix for preprocessing. Also, the metric data is very dynamic. So, what we do is process the metric with some custom code, and hold an in memory cache of every metric seen and pair it with a timestamp. The program has a timer to determine when to send LLD for each item individually. This way, as soon as a new metric is seen, LLD is performed so we never miss a metric. This also minimizes load on the database by enabling rediscovery every few hours for each metric/item individually, instead of sending LLD every time we process a metric file.

The reality is, the errors seen in the screenshot above seem to have no negative impact, and all items and triggers we attempt to discover with LLD are created as expected from the defined prototypes. That said, it can be confusing to see the error in the frontend like seen above. Also, can you make sure that there isn't something unexpected happening in the code?