Steps to reproduce:

1. Add the following JavaScript preprocessing code to any item:

console.error("a1: {$SNMP_COMMUNITY}");
console.error("a2: {$SNMP_COMMUNITY}");
console.error("a3: {$UNDEFINED_MACRO}");
console.error("a4: {$SNMP_COMMUNITY}");
return value; 

1. Execute the item to trigger the preprocessing.
2. Observe the result in the server log:

  1051:20250407:231354.850 [7] a1: public
  1051:20250407:231354.850 [7] a2: public
  1051:20250407:231354.850 [7] a3: {$UNDEFINED_MACRO}
  1051:20250407:231354.850 [7] a4: {$SNMP_COMMUNITY}

Result:

The first expansions of {$SNMP_COMMUNITY} (which is defined as a global macro in the default config) are performed properly.

The expansion of {$UNDEFINED_MACRO} gives the documented result (the macro reference is left as is).

However, the expansion of {$SNMP_COMMUNITY} which comes after {$UNDEFINED_MACRO} is not performed — in fact, all further user macros are not expanded properly after encountering a single undefined macro.

The same results can be observed when using a user macro defined at the host level, or using macro functions like {{$SNMP_COMMUNITY}.btoa()} — any reference to an undefined user macro stops all further macro expansion (including {{$UNDEFINED_MACRO}.btoa()}).

Also the same behavior can be observed when using the “Regular expression” preprocessing and adding multiple user macros to the “output” field — all macros after a reference to an undefined macro are left unexpanded, even though they may be defined. However, when using multiple “Regular expression” steps, the problem triggered by one step does not affect the next step.

Expected:
A reference to an undefined user macro should not prevent the expansion of other user macros after that point.

Testing with zabbix_server -R log_level_increase="preprocessing worker" turned up the following message:

  1051:20250407:233730.012 [4] cannot resolve user macros: unknown user macro "{$UNDEFINED_MACRO}"

which apparently comes from the code like https://github.com/zabbix/zabbix/blob/01c330d04fbd73b88fdb4ccadd5dde0aa4d997d9/src/libs/zbxcacheconfig/dbconfig.c#L16138 — looks like that function handles the “unknown user macro” case by stopping all further replacements, which would explain the problematic behavior.