[BUG] Legacy 40-character UDIDs all fall back to WDA port 8100 and break parallel execution

[eatbob]

Description

Running tests concurrently on multiple physical iOS devices with legacy 40-character UDIDs causes a WDA port conflict.
All affected devices are assigned local port 8100, so only the first execution starts successfully.

Steps to Reproduce

1. Connect two physical iOS devices with 40-character UDIDs without hyphens.
2. Start maestro-runner for the first device.
3. While it is running, start another execution for the second device.
4. Observe the WDA port forwarding failure.

Expected Behavior

Each device should use a different local WDA port, allowing both tests to run concurrently.

Actual Behavior

Both devices use port 8100. The second execution fails because the port is already occupied.

Environment

OS: macOS 26.2
Architecture: arm64
Xcode: 16.4
maestro-runner: 1.1.13
Executor: Native WDA
Device: Physical iOS devices with legacy 40-character UDIDs

Flow File

appId: com.example.app
---
- launchApp

Error Output

WDA start failed: failed to start port forwarding:
port forward 8100->8100 failed:
listen tcp 0.0.0.0:8100: bind: address already in use

Additional Context

The issue appears to be in pkg/driver/wda/runner.go, specifically in the PortFromUDID function.

For devices with a 40-character hexadecimal UDID without hyphens, the function attempts to parse the entire UDID using strconv.ParseUint(..., 64). Since a 40-character hexadecimal value exceeds the uint64 range, parsing fails and the function falls back to port 8100.

As a result, multiple devices using this UDID format are assigned the same WDA port, causing a local port-forwarding conflict when they run concurrently.

The same implementation is present in versions 1.1.13 and 1.1.20.

[omnarayan]

Thanks @eatbob — confirmed, and your root-cause analysis is exactly right.

PortFromUDID took everything after the last hyphen and parsed it as a single uint64. A modern UUID's final group is 12 hex characters and fits fine, but a legacy 40-character UDID has no hyphen at all — so the whole 40-char hex string got parsed, overflowed uint64, errored, and fell back to port 8100 for every such device. Two legacy-UDID devices running concurrently then both tried to forward 8100, and the second failed with address already in use. Precise report — thank you.

The fix bounds the segment to its last 12 hex characters before parsing:

• A standard UUID's final group is already 12 characters, so UUID-derived ports are unchanged (pinned with a test so this can't drift).
• Legacy hyphenless UDIDs now yield distinct, in-range ports, so parallel runs get different WDA ports.
• A genuinely non-hex tail still falls back to 8100, as before.

It's covered by unit tests — including two legacy 40-char UDIDs differing only in the tail, verifying they get distinct ports rather than both collapsing to 8100.

This'll go out in the next release; I'll follow up here when it ships. Thanks again for the clear repro and for pinpointing the exact function.