-
Notifications
You must be signed in to change notification settings - Fork 29.7k
Fix Xcode cache errors #175659
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix Xcode cache errors #175659
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Code Review
This pull request correctly addresses a race condition causing intermittent iOS build failures by ensuring the wireless device discovery process is stopped at all logical exit points. The introduction of a stopPolling mechanism and its application throughout the device discovery flow is a solid approach to fixing the problem. My review includes one suggestion to refactor a method for improved code clarity and maintainability.
|
We synced offline. Here's a summary: Okay so here's the current flow for wireless device discovery: flutter/packages/flutter_tools/lib/src/runner/target_devices.dart Lines 388 to 395 in 4a04204
flutter/packages/flutter_tools/lib/src/device.dart Lines 215 to 224 in 4a04204
flutter/packages/flutter_tools/lib/src/device.dart Lines 516 to 519 in 4a04204
flutter/packages/flutter_tools/lib/src/device.dart Lines 526 to 545 in 4a04204
flutter/packages/flutter_tools/lib/src/ios/devices.dart Lines 245 to 251 in 4a04204
flutter/packages/flutter_tools/lib/src/macos/xcdevice.dart Lines 444 to 462 in 4a04204
We need a solution that cancels "getAvailableIOSDevices", but only for the wireless device discovery. IDE device polling should not be impacted. One potential solution would be to introduce a new method just for wireless device discovery. In Completer<void>? _cancelCompleter;
void cancelListDevices() {
_cancelCompleter?.complete();
}
Future<List<IOSDevice>> getAvailableIOSDevicesForWirelessDiscovery({Duration? timeout}) async {
_cancelCompleter = Completer<void>();
final Completer<void> cancelCompleter = _cancelCompleter!;
final List<Object>? allAvailableDevices = await _getAllDevices(
timeout: timeout ?? const Duration(seconds: 2),
);
if (allAvailableDevices == null) {
return const <IOSDevice>[];
}
if (cancelCompleter.isCompleted) {
return const <IOSDevice>[];
}
final coreDeviceMap = <String, IOSCoreDevice>{};
if (_xcode.isDevicectlInstalled) {
final Process coreDeviceProcess = await _coreDeviceControl.startGetCoreDevices();
unawaited(
cancelCompleter.future.whenComplete(() {
coreDeviceProcess.kill(); // I'm not sure what happens if you kill a process that is completed, so may need to wrap this in a try catch or something
}),
);
await coreDeviceProcess.exitCode;
final List<IOSCoreDevice> coreDevices = _coreDeviceControl.getCoreDevicesFromProcess(coreDeviceProcess);
}
return parseDevices(allAvailableDevices, coreDeviceMap);
}Then in @override
Future<List<Device>> pollingGetDevices({Duration? timeout, bool forWirelessDiscovery = false}) async {
if (!_platform.isMacOS) {
throw UnsupportedError('Control of iOS devices or simulators only supported on macOS.');
}
if (forWirelessDiscovery) {
return xcdevice.getAvailableIOSDevicesForWirelessDiscovery(timeout: timeout);
}
return xcdevice.getAvailableIOSDevices(timeout: timeout);
}The Future<void> refreshExtendedWirelessDeviceDiscoverers({
Duration? timeout,
DeviceDiscoveryFilter? filter,
}) async {
await Future.wait<List<Device>>(<Future<List<Device>>>[
for (final DeviceDiscovery discoverer in _platformDiscoverers)
if (discoverer.requiresExtendedWirelessDeviceDiscovery)
discoverer.discoverDevices(timeout: timeout, forWirelessDiscovery: true),
]);
}Then could do something like void stopExtendedWirelessDeviceDiscoverers() {
for (final DeviceDiscovery discoverer in _platformDiscoverers) {
if (discoverer is IOSDevices) {
discoverer.cancelListDevices();
}
}
} |
This PR fixes a race condition that causes intermittent build failures on iOS with errors like no such file or directory. These failures were frequently observed in CI tests running on macOS. The root cause is that the background wireless device discovery process, which uses `devicectl`, was not being terminated after a target device was selected. This background process could then delete Xcode's module caches while `xcodebuild` was actively using them, leading to a build failure. The fix ensures that the wireless device discovery process is explicitly stopped at all logical exit points of the device discovery flow. This is achieved by calling stopExtendedWirelessDeviceDiscovery() as soon as: - A single specified device is found and validated. - An ephemeral device is chosen. - A user interactively selects a device from a list. - The discovery process concludes in a non-interactive environment (like CI). This change prevents the devicectl process from running concurrently with the app build, thus resolving the race condition and improving the reliability of iOS builds. ### Testing: - This is tested by checking the bringup to make sure the following tests are passing: * [Mac_arm64_ios integration_test_test_ios](https://ci.chromium.org/ui/p/flutter/builders/prod/Mac_arm64_ios%20integration_test_test_ios?limit=200) * [Mac_ios wide_gamut_ios](https://ci.chromium.org/ui/p/flutter/builders/prod/Mac_ios%20wide_gamut_ios?limit=200) * [Mac_ios native_assets_ios](https://ci.chromium.org/ui/p/flutter/builders/prod/Mac_ios%20native_assets_ios?limit=200) * [Mac_ios spell_check_test](https://ci.chromium.org/ui/p/flutter/builders/prod/Mac_ios%20spell_check_test?limit=200) * [Mac_ios channels_integration_test_ios](https://ci.chromium.org/ui/p/flutter/builders/prod/Mac_ios%20channels_integration_test_ios?limit=200) fixes flutter#174444 ## Pre-launch Checklist - [X] I read the [Contributor Guide] and followed the process outlined there for submitting PRs. - [X] I read the [Tree Hygiene] wiki page, which explains my responsibilities. - [X] I read and followed the [Flutter Style Guide], including [Features we expect every widget to implement]. - [X] I signed the [CLA]. - [X] I listed at least one issue that this PR fixes in the description above. - [ ] I updated/added relevant documentation (doc comments with `///`). - [X] I added new tests to check the change I am making, or this PR is [test-exempt]. - [ ] I followed the [breaking change policy] and added [Data Driven Fixes] where supported. - [X] All existing and new tests are passing. If you need help, consider asking for advice on the #hackers-new channel on [Discord]. **Note**: The Flutter team is currently trialing the use of [Gemini Code Assist for GitHub](https://developers.google.com/gemini-code-assist/docs/review-github-code). Comments from the `gemini-code-assist` bot should not be taken as authoritative feedback from the Flutter team. If you find its comments useful you can update your code accordingly, but if you are unsure or disagree with the feedback, please feel free to wait for a Flutter team member's review for guidance on which automated comments should be addressed. <!-- Links --> [Contributor Guide]: https://github.com/flutter/flutter/blob/main/docs/contributing/Tree-hygiene.md#overview [Tree Hygiene]: https://github.com/flutter/flutter/blob/main/docs/contributing/Tree-hygiene.md [test-exempt]: https://github.com/flutter/flutter/blob/main/docs/contributing/Tree-hygiene.md#tests [Flutter Style Guide]: https://github.com/flutter/flutter/blob/main/docs/contributing/Style-guide-for-Flutter-repo.md [Features we expect every widget to implement]: https://github.com/flutter/flutter/blob/main/docs/contributing/Style-guide-for-Flutter-repo.md#features-we-expect-every-widget-to-implement [CLA]: https://cla.developers.google.com/ [flutter/tests]: https://github.com/flutter/tests [breaking change policy]: https://github.com/flutter/flutter/blob/main/docs/contributing/Tree-hygiene.md#handling-breaking-changes [Discord]: https://github.com/flutter/flutter/blob/main/docs/contributing/Chat.md [Data Driven Fixes]: https://github.com/flutter/flutter/blob/main/docs/contributing/Data-driven-Fixes.md
This PR fixes a race condition that causes intermittent build failures on iOS with errors like no such file or directory. These failures were frequently observed in CI tests running on macOS.
The root cause is that the background wireless device discovery process, which uses
devicectl, was not being terminated after a target device was selected. This background process could then delete Xcode's module caches whilexcodebuildwas actively using them, leading to a build failure.The fix ensures that the wireless device discovery process is explicitly stopped at all logical exit points of the device discovery flow. This is achieved by calling stopExtendedWirelessDeviceDiscovery() as soon as:
A single specified device is found and validated.
An ephemeral device is chosen.
A user interactively selects a device from a list.
The discovery process concludes in a non-interactive environment (like CI).
This change prevents the devicectl process from running concurrently with the app build, thus resolving the race condition and improving the reliability of iOS builds.
Testing:
fixes #174444
Pre-launch Checklist
///).If you need help, consider asking for advice on the #hackers-new channel on Discord.
Note: The Flutter team is currently trialing the use of Gemini Code Assist for GitHub. Comments from the
gemini-code-assistbot should not be taken as authoritative feedback from the Flutter team. If you find its comments useful you can update your code accordingly, but if you are unsure or disagree with the feedback, please feel free to wait for a Flutter team member's review for guidance on which automated comments should be addressed.