Multiple rounds of startup tests, startup errors

[KinmoCode]

{"level":"error","msg":"error reading dtx connection read tcp [fd71:f768:7aae::2]:54384-\u003e[fd71:f768:7aae::1]:57808: read: connection reset by peer","time":"2024-10-28T15:38:47+08:00"}
{"channel_id":"com.apple.instruments.server.services.processcontrol","error":"Timed out waiting for response for message:5 channel:0","level":"error","msg":"failed requesting channel","time":"2024-10-28T15:38:52+08:00"}
{"bundleID":"com.moji.MojiWeather","channel_id":"com.apple.instruments.server.services.processcontrol","level":"info","msg":"Launching process","time":"2024-10-28T15:38:52+08:00"}
{"level":"error","msg":"DeviceConnection failed writing 1437 bytes, only 0 sent","time":"2024-10-28T15:38:52+08:00"}
{"level":"error","msg":"Failed sending: write tcp [fd71:f768:7aae::2]:54384-\u003e[fd71:f768:7aae::1]:57808: write: broken pipe","time":"2024-10-28T15:38:52+08:00"}
{"channel_id":"com.apple.instruments.server.services.processcontrol","error":"write tcp [fd71:f768:7aae::2]:54384-\u003e[fd71:f768:7aae::1]:57808: write: broken pipe","level":"info","methodselector":"launchSuspendedProcessWithDevicePath:bundleIdentifier:environment:arguments:options:","msg":"failed starting invoking method","time":"2024-10-28T15:38:52+08:00"}
{"channel_id":"com.apple.instruments.server.services.processcontrol","error":"write tcp [fd71:f768:7aae::2]:54384-\u003e[fd71:f768:7aae::1]:57808: write: broken pipe","level":"error","msg":"failed starting process: com.moji.MojiWeather","time":"2024-10-28T15:38:52+08:00"}
{"err":"write tcp [fd71:f768:7aae::2]:54384-\u003e[fd71:f768:7aae::1]:57808: write: broken pipe","level":"fatal","msg":"launch app command failed","time":"2024-10-28T15:38:52+08:00"}

[tareksalem]

any findings regarding this issue? I am facing this also

[danielpaulus]

Current read on this (also for @tareksalem): the instruments/processcontrol dtx connection goes stale after idle time or a device reboot, and the next launch runs into connection-reset/broken-pipe instead of reconnecting. The fix is reconnect-on-error in the dtx layer; that area is frozen until the e2e device suite covers it so regressions are catchable, and this is queued behind that. Related but distinct: dead tunnels themselves are being addressed in #641 via PRs #808/#809 — if your failures happen right after the tunnel has been idle, those may already help. If you can reproduce on the latest release, --verbose logs of a failing round would help confirm the stale-connection theory.