Problem
For the following situation:
/tmp/helix/working/B4C3099A/w/B5B9096D/e/System.Private.Uri.Unit.Tests.app --output-directory /tmp/helix/working/B4C3099A/w/B5B9096D/uploads
XHarness command issued: apple test --app /tmp/helix/working/B4C3099A/w/B5B9096D/e/System.Private.Uri.Unit.Tests.app --output-directory /tmp/helix/working/B4C3099A/w/B5B9096D/uploads --target ios-simulator-64 --timeout 00:30:00 --xcode /Applications/Xcode115.app -v --launch-timeout 00:03:00
[03:36:48] info: Preparing run for ios-simulator-64
[03:36:49] info: Looking for available ios-simulator-64 simulators..
[03:36:49] dbug: Looking for available ios-simulator-64 simulators. Storing logs into list-ios-simulator-64-20220406_033649.log
[03:40:11] info: Found simulator device 'iPhone X (iOS 13.5) - created by XHarness'
[03:40:11] info: Getting app bundle information from '/tmp/helix/working/B4C3099A/w/B5B9096D/e/System.Private.Uri.Unit.Tests.app'..
[03:40:11] dbug:
[03:40:11] dbug: Running /usr/libexec/PlistBuddy -c "Print CFBundleName" /tmp/helix/working/B4C3099A/w/B5B9096D/e/System.Private.Uri.Unit.Tests.app/Info.plist
[03:40:11] dbug: Process PlistBuddy exited with 137
[03:40:11] fail: Failed to get bundle information: Killing process 723 as it was cancelled
[03:40:11] dbug: Saving diagnostics data to '/tmp/helix/working/B4C3099A/w/B5B9096D/e/diagnostics.json'
XHarness exit code: 4 (PACKAGE_NOT_FOUND)
What happened is that the aggressive --launch-timeout expired which stopped the process of reading app information.
The result of this run should be a launch timeout, launch failure or similar (something that will be retried).
Similarly, if looking for the device took longer and would be cancelled in the same way, we shouldn't report DEVICE_NOT_FOUND (not sure this is happening but all actions cancelled by this should result in a retriable exit code).
To be done
- Consider the state of the launch timeout token when failures occur. This token eventually expires but if we manage to launch the app by then, we should stop taking it into account.
- The orchestrator class should be checking for
IsCancellationRequested in between the various operations and return a failing exit code as well so that we also implement part of the cancellation process and don't have to wait for ProcessManager calls to be cancelled.
Problem
For the following situation:
What happened is that the aggressive
--launch-timeoutexpired which stopped the process of reading app information.The result of this run should be a launch timeout, launch failure or similar (something that will be retried).
Similarly, if looking for the device took longer and would be cancelled in the same way, we shouldn't report
DEVICE_NOT_FOUND(not sure this is happening but all actions cancelled by this should result in a retriable exit code).To be done
IsCancellationRequestedin between the various operations and return a failing exit code as well so that we also implement part of the cancellation process and don't have to wait forProcessManagercalls to be cancelled.