Maybe it's a bug, maybe it's not. I tried to make it thoroughly investigate it and figure it out. It's hard on thinking this is a bug. Where is the best place to get this in front of zabbix devs?
Zabbix Support Case: Newly-created trapper items reject all incoming data (even after full server restart)
Summary
On our Zabbix 7.4.11 server, any newly-created trapper item rejects all incoming `zabbix_sender` data (`processed: 0; failed: N`). This persists after `config_cache_reload` and after a full `systemctl restart zabbix-server`. Meanwhile:
Pre-existing (old) trapper items accept data normally.
Newly-created dependent items and script items work fine (collect data immediately).
So the failure is cleanly isolated to newly-created items of type "Zabbix trapper."
Environment
Zabbix server 7.4.11 (DB version 7040011), single node (HA manager reports one active node, no standby).
MariaDB 11.8.3 backend on a separate host.
~1,181 monitored hosts, ~227,000 enabled items.
No Zabbix proxies. Single `zabbix_server` instance (verified via `ss`/`ps`).
Reproduction
Create a new trapper item (e.g. `key=zz.trapper.test`, type "Zabbix trapper", unsigned) on any host — existing or new, normal or LLD-discovered.
`zabbix_server -R config_cache_reload` (also tried waiting >60s, and 40+ min).
`zabbix_sender -z 127.0.0.1 -p 10051 -s "<host>" -k zz.trapper.test -o 1 -vv`
→ server response: `processed: 0; failed: 1; total: 1`
Full `systemctl restart zabbix-server`, wait for startup, repeat step 3 → still `processed: 0; failed: 1`.
A byte-identical old trapper item on another host returns `processed: 1; failed: 0` in the same test.
Ruled out
Proxy: none configured; host `proxyid=0`, `monitored_by=0`.
Duplicate/second server instance / HA split-brain: single `zabbix_server` parent PID; `ha_node` shows a single node in status=3 (active).
Allowed hosts (item `trapper_hosts`): empty (= any) on both working and failing items.
Item/host state: failing item `status=0` (enabled), `state=0` (normal); host `status=0` (monitored).
Config cache exhaustion: "Configuration cache, % used" = ~4.7%.
Timing / cache delay: failure persists far beyond the 60s cache window and across a full restart.
Broken changelog triggers: `changelog` table present and actively recording (newest row seconds old); `items`/`hosts` insert/update/delete triggers all present. 65 DB triggers total.
Server health: configuration syncer utilization ~1.2%, history write cache 0% used, history syncers ~3% busy — nothing overloaded.
Impact
New `zabbix_sender`/trapper-based monitoring cannot be added to this server (data is silently rejected). Existing trapper items and all other item types are unaffected, so day-to-day monitoring continues.
Notes / suspected area
Behavior is consistent with the incremental (changelog-based) configuration synchronization not applying newly-added trapper items to the live config cache used by the trapper listener — but even a full config rebuild at server startup does not resolve it, which is the unusual part. Not referenced as fixed in release notes 7.4.12 or 7.4.13rc1.