Unexpected endOfMIB tree message

[jeff2zhang]

I was playing around with the previous minimal-agent.py script https://github.com/hosthvo/pyagentx/blob/master/minimal-agent.py, with PyAgentX3 it looks like

#!/usr/bin/env python
# -*- coding: utf-8 -*-
import pyagentx3

# Updater class that set OID values
class NetSnmpPlaypen(pyagentx3.Updater):
    def update(self):
        self.set_INTEGER('1.0', 1000)
        self.set_OCTETSTRING('3.0', 'String for NET-SNMP-EXAMPLES-MIB')


class MyAgent(pyagentx3.Agent):
    def setup(self):
        # Register Updater class that responsd to
        # the tree under "netSnmpPlaypen": 1.3.6.1.4.1.8072.9999.9999
        self.register('1.3.6.1.4.1.8072.9999.9999', NetSnmpPlaypen)


# Main 
pyagentx3.setup_logging()
try:
    a = MyAgent()
    a.start()
except Exception as e:
    a.stop()
except KeyboardInterrupt:
    a.stop()

After hooking the script up with snmpd with these in the config
view systemview included .1.3.6.1.4.1.8072.9999.9999
master agentx
I was able to snmpwalk the OIDs

user@host:~$ snmpwalk -v2c -c "<redacted>" 127.0.0.1 1.3.6.1.4.1.8072
iso.3.6.1.4.1.8072.9999.9999.1.0 = INTEGER: 1000
iso.3.6.1.4.1.8072.9999.9999.3.0 = STRING: "String for NET-SNMP-EXAMPLES-MIB"
iso.3.6.1.4.1.8072.9999.9999.3.0 = No more variables left in this MIB View (It is past the end of the MIB tree)

However as you can see the last OID in the tree was returned twice when you walk its parent node.
Even more unexpectedly, walking the last OID directly doesn't return the value (endOfMIB msg only when I was expecting both the value + endOfMIB maybe) while getting the OID directly works.

user@host:~$ snmpwalk -v2c -c "<redacted>" 127.0.0.1 1.3.6.1.4.1.8072.9999.3.0
iso.3.6.1.4.1.8072.9999.3.0 = No Such Object available on this agent at this OID
user@host:~$ snmpget -v2c -c "<redacted>" 127.0.0.1 1.3.6.1.4.1.8072.9999.3.0
iso.3.6.1.4.1.8072.9999.3.0 = No Such Object available on this agent at this OID

This doesn't seem to be the behavior for other non-agentx OIDs (walking a the last/terminal key behaves like a get). Is this just some quirkiness with the agentx protocol or this particular implementation?