Closed rerorero closed 1 year ago
The connection issue on CI has not been fixed. I'll take a look deeper into it.
Error: The device '5C59AF64-552A-464A-B042-6A162876029E' is not responding to idb requests after 60000ms timeout. Original error: Failed to connect to companion at address DomainSocketAddress(path='/tmp/idb/5C59AF64-552A-464A-B042-6A162876029E_companion.sock')
I think test will get fixed by merging this https://github.com/appium/appium-idb/pull/63
hmm.. xctest tests seems flakey. Let me extend the retry interval.
Now the tests have passed, please take a look.
This PR proposes to stop manually starting the companion process. Instead, you can let idb command manage the connections.
idb
command looks for a running companion process associated with the given udid and it spanws a new companion process if not found. Also it just uses the existing one if found. Once it connects to the companion, idb stores the association info in its state (/tmp/idb/state). This state is not created when you manually runidb_companion
.idb
lets companion to use unix domain socket instead of tcp if port is not specified. Because idb creates a unique UDS file for each udid, you don't need to care about the port conflicts e.g./tmp/idb/42372A50-5AF6-472F-973A-3F4C6DE56255_companion.sock
I'd expect that this fixes the address already in use error
and also fixes this CI issue since it tried to connect via UDS somehow while a companion process listens on tcp.> this is another issue, see https://github.com/appium/appium-idb/pull/66However, as the document mentions, using grpc enables you to expose a companion over the network to another machine. If this is needed, it'd be better to make grpc port configurable instead of this approach.