Describe what happens and when:

Official MSSQL template 'MSSQL by Zabbix agent 2' contains multiple sources for this cause, to name a few, it is LLDs: Local database discovery, Non-local database discovery, Replication discovery.

Issue is seen occuring (infrequently) when LLD is of type dependent on itemA and has item prototypes with JSONPath preprocessing that also depend on itemA.

Occasionally, those item prototypes may become unsupported with error similar to this one (coming from Replication discovery):
1. Failed: cannot extract value from json by path "$[?(@.replica_name=='XXXX\\QA_TCEU' && @.group_name=='QATCEU')].synchronization_health.first()": no data matches the specified path

Note that this DOES NOT HAPPEN for all item prototypes within the same discovery, just for couple of them.

It is needed to say that if the initial JSON did not contain relevant data for the discovered object, item prototype would become NOT DISCOVERED instead of NOT SUPPORTED.

When I manually modified the master item to see the history, that JSON was complete and contained all the relevant data, therefore I believe this is some race condition that occurs during resolution of dependent items.

Workaround

Define LLD macros for all properties of an object.

Replace JSONPath with Regular expression, where pattern matches the whole string and the output is LLD macro containing value for the particular property.

I did not see issues with this approach.

Wrap up

Despite the need for having this fixed, I would also like to point out a feature request ZBXNEXT-10687, where I mention the need for another item type or different approach to these item prototypes dependent on the same master item as the LLD, where it would be great, if the user could simply set the value of that item prototype to LLD macro, instead of having to choose the dependent item type which results in extra preprocessing.