Test suite can't run the DBus mock tests without weird failures

Traceback (most recent call last):
  File "/home/barry/projects/phone/client/systemimage/tests/test_dbus.py", line 69, in setUp
    'com.canonical.SystemImage', '/Service')
  File "/usr/lib/python3/dist-packages/dbus/bus.py", line 241, in get_object
    follow_name_owner_changes=follow_name_owner_changes)
  File "/usr/lib/python3/dist-packages/dbus/proxies.py", line 248, in __init__
    self._named_service = conn.activate_name_owner(bus_name)
  File "/usr/lib/python3/dist-packages/dbus/bus.py", line 175, in activate_name_owner
    return self.get_name_owner(bus_name)
  File "/usr/lib/python3/dist-packages/dbus/bus.py", line 361, in get_name_owner
    's', (bus_name,), **keywords)
  File "/usr/lib/python3/dist-packages/dbus/connection.py", line 651, in call_blocking
    message, timeout)
dbus.exceptions.DBusException: org.freedesktop.DBus.Error.NoReply: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.

My best guess at what is happening is this:

The first time we connect to the special system bus, the dbus client is not yet initialized. I can see how init_connections_unlocked() in dbus-bus.c digs out $DBUS_SYSTEM_BUS_ADDRESS for the bus connection address, but it only does this if the connections are not yet initialized, as would be the case at first.

When the second set of tests run, we've started up a new dbus-daemon, which of course lives on a different DBUS_SYSTEM_BUS_ADDRESS, however, because the client side running the tests is in the same process as the first set of tests, perhaps init_connections_unlocked() thinks it's already initialized and so does not dig out the new DBUS_SYSTEM_BUS_ADDRESS.

If so, I'm not sure what can be done, except to run the test suite in a separate process so that the dbus client side gets initialized again every time.

Oh, I should note what led me to this. When I set a breakpoint just after the dbus-daemon invocation in _controller.py, get the new DBUS_SYSTEM_BUS_ADDRESS and use that in a separate Python 3 process, it connects to the new bus just fine.

Indeed, this behavior has been confirmed by upstream. I have a workaround that should be reliable.