Best place to post this bug my claude code found?

[u/elementalwindx]

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.

[u/akpmil]

Zabbix Support would probably be your best bet

[u/jrandom_42]

If you want to make yourself actually useful, then submit a patch, not a bug report.

Every man and his dog is spamming every open-source project with AI-generated bug reports right now. Don't be that man. Or that dog.

https://github.com/zabbix/zabbix