Today, the mock network fixture is a single threaded process that mimics two threads – the component that is being tested, and the network responses. Any time the component issues a network command, the mock network passes control of the thread over to the network responses, which then "responds" to the command, feeds the response to the component, and relinquishes control.

This means that the mock network interface does not work well with any network command that explicitly waits for the network to complete before continuing, such as this case. This is because the component will self-deadlock on waiting for the response – the ThreadPoolMock will be stuck here, waiting for the response, and it will never signal the network via _net->waitForWork() to allow the response to actually process.

We should document this issue to make it clear that blocking on a callback will cause unit tests using the mock network to document. The mock network logic is complex, so any attempts to make it easier to work with would probably require a decent time investment. But this could also be considered within this ticket.