It appears that when we handle duplicate SNMPv3 security names as part of trap processing, we are attempting to iterate through the v3 credentials to decode a trap even when the trap is v1 or v2, resulting in spurious error messages:

This reproduces on Horizon 30 as well.

This caused a ton of confusion for the customer, who rightly thought support had been removed for v1 and v2 traps, and that these traps were being dropped and events lost.