Corruption of _nodes property of Interface

[Goose66]

Initially (i.e., after final config), poly._nodes is a dictionary containing items comprising <node_addr> : <node_data_dict> for each node that is read from the database. When we call addNode, the interface adds the node object to both nodes_internal and _nodes dictionaries. After adding at least one node, poly._nodes becomes "corrupt" in that it contains some items <node_addr> : <node_data_dict> and some items <node_addr> : <node_object>. If you are iterating through poly._nodes mutliple times (e.g., during initial recreation of nodes while retaining node hierarchy), then the second time through you may get failures because of the corruption of the _nodes dictionary.

[Goose66]

Proposed Solutions

1. Don't update _nodes in addNode() call. The comments say "addNode will copy driver values from _nodes and replace the default values before sending to core - that's really the only thing _nodes is used for." However, addNode() doesn't actually do this, and _nodes is not really referenced anywhere else. So just leave _nodes as a dictionary of node data read in the initial config and be done. We could rename _nodes to something else, like initialNodes or configNodes, in order to "bring it out of the shadows" in the API, but this would affect existing PG3 nodeservers.
2. Add the dictionary of node data sent with the MQTT message to _nodes in the addNode() call instead of the object. For example:

def addNode(self, node, conn_status=None):
...
    node_data = {
        'address': node.address,
        'name': node.name,
        'nodeDefId': node.id,
        'primaryNode': node.primary,
        'drivers': node.drivers,
        'hint': node.hint,
        'private': node.private
    }        
    message = {'addnode': [node_data]}

    self.send(message, 'command')
    self._nodes[node.address] = node_data
    self.nodes_internal[node.address] = node.

Workaround
As to use of poly. _nodes in a nodeserver for recreation of nodes on start, the simple workaround is to make a shallow copy of poly._nodes and work from that to spin through (multiple times) and recreate your node hierarchy.

[bpaauwe]

This should be fixed in version 3.0.34 of udx_interface.

A new method has been added to the interface, getDriversFromDb() that gets either a driver list for a specified address or the list of nodes if no address is given. The lists should mirror what's in the database. getDriversFromDb() replaces db_getNodeDrivers() although it will continue to work for backward compatibility.

[Goose66]

Note that this is called "getNodesFromDb()" instead of "getDriversFromDb()," but "getDriversFromDb()" is still listed in API.md. Also, note that this doesn't actually get anything from the database - simply returns a slightly altered form of the internal _nodes collection, which is built during initial config load, but not updated during the running of the node server (e.g., by subsequent addNode() calls or setDriver() calls). This should probably be noted in the API.md document as well.

[bpaauwe]

Noted and updated.