There is an amusing but undesirable circle of interactions between several of our standard tools, in their respective approaches to minimizing the remaining legacy data structures. The details will emerge below, but the analysis and actionable items are the following:

(1) this was revealed by a recent analysis of the bug coincidentally reported in T6638; it had been triggered in debugging the PR for T6633 (for which the PR was pulled back to draft).

• this is not the root cause of T6638, but its behavior under T6633 revealed this collection of issues, and provides some information useful for T6638, namely,
• recommendation: (at the discretion of the developer working on T6638) the function verify_interface_exists should take a config argument, analogous to the other functions in configverify.py; in practice, this arg refers to the config_dict of the working config. Using ConfigTreeQuery will not return the working config under configd currently, and invites a problem when utils/configfs is involved:

(2) injecting the environment vars needed for the configfs utils into the configd context (T6633) has the following side effect: a check of whether we are in a config session will now return True. This contradicts the separation of concerns that is the basis for configd.

• the problem is mooted if never acted upon: the recommendation above to drop ConfigTreeQuery in the verify function will resolve that immediate problem; no explicit use of configsession.py is in configd (by design).
• subtask: (T6640) any wrapper to the cli-shell-apicheck inSession should return False if running under configd.

(3) ConfigTreeQuery should not be included explicitly in config mode scripts, nor is it currently. However, any implicit inclusions (beyond the one mentioned above) need to be checked: vyos/ifconfig/vrrp.py, for example.

• subtask: check necessity of class for ifconfig/vrrp.py; most likely this is not the correct approach for reading the configuration in that case.