stf issue #387

kliu2python · 2025-10-30T23:13:35Z

kliu2python
Oct 30, 2025

Hi VK team,

Thank you for share this wonderful open source project. It really works for my purpose.

I just try to setup in my Macmini for hosting Android and iPhone together. The Devicehub is up, however there is no device shows in the list.

the docker compose I used:
docker compose -f docker-compose-macos.yaml --env-file scripts/variables.env up -d

the output of adb:
adb devices
List of devices attached
2C031JEGR00238 device
562d945a device
R5CT44LW5LX device
RFCN80T4GDJ device

the output of idevice_id:
idevice_id -l
00008030-0018145A1A63402E
f67d7ce40691d9ab546d7362a4cc7a6182870de2
00008110-00061C390C40401E
00008101-00040DEE34B9001E
05bf6eed0a0744d8d2acf2cc7164b3dac9288aba

After researching, found that we need to start the provider. While I tried the provider command line, like ios-provider, it shows:

input:
stf ios-provider
--provider localworker
--host "$PROXY_HOST"
--secret "$AUTH_SECRET"
--connect-sub tcp://$PROXY_HOST:7114
--connect-push tcp://$PROXY_HOST:7116
--connect-app-dealer tcp://$PROXY_HOST:7112
--connect-dev-dealer tcp://$PROXY_HOST:7115
--public-ip "$PROXY_HOST"
--screen-ws-url-pattern "ws://$PROXY_HOST:<%= publicPort %>"
--storage-url http://$PROXY_HOST:7100/
--port-range-min 8100 --port-range-max 8200
--screen-ws-range-min 9200 --screen-ws-range-max 9250
--wda-range-min 18200 --wda-range-max 18300
--wda-path "/Users/fortinet/.appium/node_modules/appium-xcuitest-driver/node_modules/appium-webdriveragent"

output:
Initialized sentry for environment: unset
Warning: Sentry sample_rate is 0
2025-10-30T23:09:47.368Z unknown INF/console 33895 [] 10.160.13.112
2025-10-30T23:09:48.696Z ios-provider ERR/console 33895 [] TypeError: The "paths[0]" argument must be of type string. Received undefined
at __node_internal_captureLargerStackTrace (node:internal/errors:496:5)
at new NodeError (node:internal/errors:405:5)
at validateString (node:internal/validators:162:11)
at Object.resolve (node:path:1115:7)
at Object.handler (file:///Users/fortinet/devicehub/lib/cli/ios-provider/index.js:170:22)
at file:///Users/fortinet/devicehub/node_modules/yargs/build/lib/command.js:206:54
at maybeAsyncResult (file:///Users/fortinet/devicehub/node_modules/yargs/build/lib/utils/maybe-async-result.js:9:15)
at CommandInstance.handleValidationAndGetResult (file:///Users/fortinet/devicehub/node_modules/yargs/build/lib/command.js:205:25)
at CommandInstance.applyMiddlewareAndGetResult (file:///Users/fortinet/devicehub/node_modules/yargs/build/lib/command.js:245:20)
at CommandInstance.runCommand (file:///Users/fortinet/devicehub/node_modules/yargs/build/lib/command.js:128:20)
at YargsInstance.[runYargsParserAndExecuteCommands] (file:///Users/fortinet/devicehub/node_modules/yargs/build/lib/yargs-factory.js:1386:105)
at YargsInstance.parse (file:///Users/fortinet/devicehub/node_modules/yargs/build/lib/yargs-factory.js:707:63)
at file:///Users/fortinet/devicehub/lib/cli/index.js:83:6

where should I make change to make the Devicehub works for Android and iPhone together?

Thank you for your help.
Kevin

e-khalilov · 2025-10-31T13:45:35Z

e-khalilov
Oct 31, 2025
Collaborator

Hi! To connect devices, you need to start the corresponding providers. For Android, it's simply called provider, and for iOS, it's ios-provider.

The docker-compose-macos.yaml already starts a container named devicehub-provider—this is the provider for Android devices. However, for iOS devices, you need to start a new process with the required TCP endpoints. To work with docker-compose-macos.yaml:

stf ios-provider \
    --connect-sub tcp://devicehub-triproxy-dev:7250 \
    --connect-push tcp://devicehub-triproxy-app:7170 \
    --connect-app-dealer tcp://devicehub-triproxy-app:7160 \
    --connect-dev-dealer tcp://devicehub-triproxy-dev:7260 \
    --screen-ws-url-pattern 'ws://localhost:<%= publicPort %>' \
    --public-ip localhost \
    --provider localworker \
    --storage-url https://${STF_DOMAIN}:${STF_PORT}/

If you run devicehub local, you can use the following settings to connect to the local farm:

stf ios-provider \
    --connect-sub tcp://127.0.0.1:7114 \
    --connect-push tcp://127.0.0.1:7116 \
    --connect-app-dealer tcp://127.0.0.1:7112 \
    --connect-dev-dealer tcp://127.0.0.1:7115 \
    --screen-ws-url-pattern 'ws://localhost:<%= publicPort %>' \
    --public-ip localhost \
    --provider localworker \
    --storage-url http://localhost:7100

You can use devicehub --help to examine all running units, and using devicehub <unit> --help you can see all possible cli arguments for a given unit and its description.

Make sure that the provider containers have network access to your adb server to which the devices are connected. Also, make sure you've set a trusted provisioning profile for the WebDriverAgent (in the project root) in XCode so the ios-provider can install the tool needed to interact with iOS devices.

0 replies

kliu2python · 2025-10-31T15:56:41Z

kliu2python
Oct 31, 2025
Author

Thanks @e-khalilov

I figure it out the issue in my end of provider (includes provider and ios-provider)

diff --git a/lib/cli/provider/index.js b/lib/cli/provider/index.js
index ff19d4e..0b0e12f 100644
--- a/lib/cli/provider/index.js
+++ b/lib/cli/provider/index.js
@@ -1,6 +1,7 @@
 import os from 'os'
 import ip from 'my-local-ip'
 import path from 'path'
+import { fileURLToPath } from 'node:url'
 import provider from '../../units/provider/index.js'
 import {fork} from 'child_process'
 export const command = 'provider [serial..]'
@@ -223,7 +224,7 @@ export const builder = function(yargs) {
         '`STF_PROVIDER_NAME`).')
 }
 export const handler = function(argv) {
-    var cli = path.resolve(import.meta.dirname, '..')
+    var cli = fileURLToPath(new URL('..', import.meta.url))
     function range(from, to) {
         var items = []
         for (var i = from; i <= to; ++i) {

looks like the path is not working well in my environment: node 19. After change it, the Android phone shows as expected.

0 replies

kliu2python · 2025-10-31T17:22:30Z

kliu2python
Oct 31, 2025
Author

Hi! To connect devices, you need to start the corresponding providers. For Android, it's simply called provider, and for iOS, it's ios-provider.

The docker-compose-macos.yaml already starts a container named devicehub-provider—this is the provider for Android devices. However, for iOS devices, you need to start a new process with the required TCP endpoints. To work with docker-compose-macos.yaml:

stf ios-provider
--connect-sub tcp://devicehub-triproxy-dev:7250
--connect-push tcp://devicehub-triproxy-app:7170
--connect-app-dealer tcp://devicehub-triproxy-app:7160
--connect-dev-dealer tcp://devicehub-triproxy-dev:7260
--screen-ws-url-pattern 'ws://localhost:<%= publicPort %>'
--public-ip localhost
--provider localworker
--storage-url https://${STF_DOMAIN}:${STF_PORT}/
If you run devicehub local, you can use the following settings to connect to the local farm:

stf ios-provider
--connect-sub tcp://127.0.0.1:7114
--connect-push tcp://127.0.0.1:7116
--connect-app-dealer tcp://127.0.0.1:7112
--connect-dev-dealer tcp://127.0.0.1:7115
--screen-ws-url-pattern 'ws://localhost:<%= publicPort %>'
--public-ip localhost
--provider localworker
--storage-url http://localhost:7100
You can use devicehub --help to examine all running units, and using devicehub <unit> --help you can see all possible cli arguments for a given unit and its description.

Make sure that the provider containers have network access to your adb server to which the devices are connected. Also, make sure you've set a trusted provisioning profile for the WebDriverAgent (in the project root) in XCode so the ios-provider can install the tool needed to interact with iOS devices.

Hi @e-khalilov

I tried your command line in my environment. It's processing, but never stop. Keep build the WDA and test in my devices. This is part of log:

2025-10-31 10:19:22.503697-0700 WebDriverAgentRunner-Runner[22427:17857988] Built at Oct 30 2025 20:48:00
2025-10-31 10:19:22.516670-0700 WebDriverAgentRunner-Runner[22427:17857988] ServerURLHere->http://192.168.8.3:8100<-ServerURLHere
2025-10-31T17:19:22.473Z ios-device INF/device:support:push 77750 [*] Device sending output to "tcp://devicehub-triproxy-app:7170"
2025-10-31T17:19:22.473Z ios-device VRB/util:zmqutil 77750 [*] Socket connected to: tcp://devicehub-triproxy-app:7170
2025-10-31T17:19:22.474Z ios-device WRN/wire:legacy 77750 [*] Legacy contstructor lookup for DeviceLogMessage
2025-10-31T17:19:22.473Z ios-device INF/ios-device 77750 [*] Preparing device options: [object Object]
2025-10-31T17:19:22.477Z ios-device FTL/util:lifecycle 77750 [*] Shutting down due to fatal error Error: spawnSync idb ENOENT
2025-10-31T17:19:22.497Z ios-provider INF/ios-provider 68071 [*] Cleaning up worker after 00008101-00040DEE34B9001E
2025-10-31T17:19:22.497Z ios-provider DBG/ios-provider 68071 [*] Stopped wda forwarder
2025-10-31T17:19:22.498Z ios-provider DBG/ios-provider 68071 [*] Stopped screen forwarder
2025-10-31T17:19:22.498Z ios-provider INF/ios-provider 68071 [*] Cleaned up worker after 00008101-00040DEE34B9001E
2025-10-31T17:19:22.498Z ios-provider INF/ios-provider 68071 [*] And restarting...
2025-10-31T17:19:22.498Z ios-provider INF/ios-provider 68071 [*] Starting worker for 00008101-00040DEE34B9001E [device]
2025-10-31T17:19:22.498Z ios-provider INF/ios-provider 68071 [*] Starting port forwarding for device 00008101-00040DEE34B9001E

the build WDA is good, but the test sometime failed. Is test necessary and failure will block the ios-provider?

thanks,
Kevin

1 reply

irdkwmnsb Nov 2, 2025
Maintainer

Hi! It looks like you are missing the idb cli tool. Make sure it's installed. See this: https://github.com/facebook/idb

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

stf issue #387

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{editor}}'s edit

{{editor}}'s edit

Uh oh!

Replies: 3 comments 1 reply

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{title}}

Uh oh!

Select a reply

Uh oh!

stf issue #387

Uh oh!

Uh oh!

kliu2python Oct 30, 2025

Replies: 3 comments · 1 reply

Uh oh!

e-khalilov Oct 31, 2025 Collaborator

Uh oh!

kliu2python Oct 31, 2025 Author

Uh oh!

kliu2python Oct 31, 2025 Author

Uh oh!

irdkwmnsb Nov 2, 2025 Maintainer

kliu2python
Oct 30, 2025

Replies: 3 comments 1 reply

e-khalilov
Oct 31, 2025
Collaborator

kliu2python
Oct 31, 2025
Author

kliu2python
Oct 31, 2025
Author

irdkwmnsb Nov 2, 2025
Maintainer