At some point, an SNMP LLD rule stopped working. Packet capture showed that Zabbix was sending:

GetBulk
non-repeaters: 0
max-repetitions: 0
OID: 1.3.6.1.2.1.31.1.1.1.1

The device returned a successful but empty response. A manual snmpbulkwalk with max-repetitions=10 returned the expected interface table.

The issue may have appeared after replacing the router model while keeping the same management IP and changing its templates. Old direct-OID items may have temporarily continued querying unsupported OIDs on the new device. Use combined requests was enabled.

Changing the SNMP interface Max repetition count from 10 to 5 and saving immediately restored discovery. Packet capture then showed M=1, followed by M=2, M=3, and M=4. 

A possible mechanism is corruption of the shared adaptive SNMP statistics after a failed combined request fallback:

single-OID fallback fails
-> min_fail = 1
-> fallback incorrectly returns SUCCEED
-> cached state becomes max_succeed=2, min_fail=1
-> suggested vars = MAX(2-2, 1-1) = 0
-> discovery[] sends GetBulk with max-repetitions=0

This may explain why changing the SNMP interface setting temporarily resolves the issue by resetting the cached statistics.

Expected result
Legacy SNMP discovery[] should never send a GetBulk request with max-repetitions=0.

Additional information
This may be related to the shared adaptive SNMP statistics used by combined direct-OID checks and legacy discovery[].

ZBX-27953 describes the same faulty final fallback in zbx_snmp_get_values() but focuses on poller exhaustion and failure to mark a host unreachable.

ZBX-22864 does not fully prevent this case. Its guard prevents zbx_snmp_walk() from reducing an already active walk below one, but here zero is calculated earlier in the shared configuration cache and passed into the walk.