Debian 12, Firefox

Related to macro conflict resolution: ZBXNEXT-1674 and https://www.zabbix.com/documentation/current/en/manual/config/macros/user_macros for those who look for workarounds.

What do you mean by "but when LLD rule runs"? Are you referring to the macro being resolved differently in items or triggers created from prototypes?

The procedure for resolving user macros and how such conflicts are handled is described here.

I simplifyed too much, sorry.

First template has UUID 2... and macro {$VAL.IGNORE.REGEX} = ^never-ignore$,
+ a LLD rule with a filter like this: {#VAL} does not match {$VAL.IGNORE.REGEX}.
Second template has UUID f... and macro {$VAL.IGNORE.REGEX} = ^2$.
Both templates linked to one host.

When LLD rule runs, it works like described in documentation. First template wins and nothing is filtered.
But in Host > Macros > Inherited and host macros it works differently: It says macro resolves to ^2$.

Maybe it is not worth fixing but caused "My macro is ^2$ so why are these items still discovered?".

Looks like maybe order of template import matters in Frontend?

• When I import Second and then First, I get ^2$.
• When I delete Second and import and link again I get ^never-ignore$.
• When I delete First and import and link again I am back to ^2$.

Yes, the order definitely matters — identical macros are sorted by the template ID (hostmacro.hostid). Here’s an excerpt from our documentation:

If a macro with the same name exists on multiple linked templates of the same level, the macro from the template with the lowest ID will be used. Thus having macros with the same name in multiple templates is a configuration risk.

The server and frontend should behave the same way. I’ll try to reproduce the issue to confirm.

Is that AI-generated? First you agree that link order matters but then continue that conflicts are solved by template ID, not link order.

I hope the attached templates will help with reproducing.

I meant that the import order matters, not the linking order. If a template is imported first, it will have a lower ID, and therefore its macro will take precedence.

Thank you for the templates — they’ll help reproduce the issue.

Oh, I assumed that "template ID" means template UUID that will be carried by export. I see my mistake.

I don't know if attached templates will work here. Let me test the LLD part more thoroughly on my end.

Can you please try this:

• Import Second template first
• Import First template second
• Create host "A" and link to both templates - Inherited and host macros should say ^2$ because it was imported first.
• Create host "B" and link only the "First" template - Inherited and host macros should say ^never-ignore$ because there is no conflict
• Let Discovery run
• Host "A" should discover less items than host "B" because of filter
• Link "Second" template to host "B" - Now inherited and host macros should say ^2$ just like on host "A"
• Re-run discovery on "B"
• * Expected: Extra items on "B" become "not discovered anymore"
• * Actual: Nothing, all items still discovered.

• Delete all discovered items
• Re-run discovery on both hosts
• * Expected: Same number of items discovered on both
• * Acutal: Host "B" still discovers more items

Simpler test:

• Imported First template first
• Imported Second template second
• Created host "C", linked only to "First"
• Created host "D", linked only to "Second"
• Link remaining template to both hosts
• Run discovery on both hosts
• * Expected: Hosts discover same number of items
• * Actual: Host "C" discovered more items than host "D"

Thank you for your input! I can confirm the issue — the server resolves user macros without taking their priority by "hostid" into account.