Steps to reproduce:
1. Configure service.discovery LLD rule on a Windows host (Zabbix Agent 2, active checks) with a moderately large service list (payload ~21.2 KB).
2. Trigger the discovery check and capture the agent-to-server exchange on TCP port 10051.
3. Confirm on the agent: zabbix_agent2.exe -t service.discovery produces a complete, valid JSON payload.
4. Confirm on the wire: tcpdump on port 10051 shows full transmission of the payload with correct ACKs, no packet loss, no truncation.
5. Confirm on the server: zabbix_server.log confirms the trapper fully received the JSON packet.
6. Set DebugLevel=4 specifically on the LLD manager process and repeat.

Result:
No discovered items/prototypes are ever created for this rule. No error, warning, or any log entry is produced — even with DebugLevel=4 on the LLD manager. The discard is completely silent.

Attempted workarounds (none resolved the issue):

• Increasing StartLLDProcessors.
• Restarting zabbix-server.
• Deleting and fully recreating the affected hosts.

Expected:
The service.discovery rule should generate discovered items/prototypes from the received JSON, matching what the agent reported.

Searched existing reports ZBX-26609 (memory leak in LLD manager) and ZBX-18650 (SIGSEGV crash, fixed in 5.0.6/5.2.2) — neither matches this symptom; this appears to be a separate, previously unreported issue.

See attached: tcpdump capture (port 10051, compressed), zabbix_agent2 -t service.discovery output, zabbix_server.log excerpt (DebugLevel=4, discovery cycle), and zabbix_server -R diaginfo output (LLD section, showing rule processed with 0 items created).