Flutter: Cleaning Xcode workspace takes 2-3 minutes

Hey Flutter Community, I've looked at similar issues but non resemble the issue we have.

While running the usual command flutter clean we've noticed several months ago that it takes too long, nearly up to 3 minutes, which definitely is not the case for new projects. Maybe it has to do with the fact that we use too many dependencies? We're using SPM and the latest Flutter Version 3.35.1. If needed I can supply the packages we have in our pubspec.yaml.

flutter clean -v (provided as a file because it's very big with >500.000 chars): clean.txt

flutter doctor -v

[✓] Flutter (Channel stable, 3.35.1, on macOS 15.6 24G84 darwin-arm64, locale de-DE) [499ms]
    • Flutter version 3.35.1 on channel stable at /Users/emre.yurtseven/Dev/flutter
    • Upstream repository https://github.com/flutter/flutter.git
    • Framework revision 20f8274939 (4 days ago), 2025-08-14 10:53:09 -0700
    • Engine revision 1e9a811bf8
    • Dart version 3.9.0
    • DevTools version 2.48.0
    • Feature flags: enable-web, enable-linux-desktop, enable-macos-desktop, enable-windows-desktop, enable-android, enable-ios, cli-animations, enable-swift-package-manager, enable-lldb-debugging

[✓] Android toolchain - develop for Android devices (Android SDK version 36.0.0) [3,7s]
    • Android SDK at /Users/emre.yurtseven/Library/Android/sdk
    • Emulator version 36.1.9.0 (build_id 13823996) (CL:N/A)
    • Platform android-36, build-tools 36.0.0
    • Java binary at: /Library/Java/JavaVirtualMachines/amazon-corretto-17.jdk/Contents/Home/bin/java
      This JDK is specified in your Flutter configuration.
      To change the current JDK, run: `flutter config --jdk-dir="path/to/jdk"`.
    • Java version OpenJDK Runtime Environment Corretto-17.0.13.11.1 (build 17.0.13+11-LTS)
    • All Android licenses accepted.

[✓] Xcode - develop for iOS and macOS (Xcode 16.4) [1.194ms]
    • Xcode at /Applications/Xcode.app/Contents/Developer
    • Build 16F6
    • CocoaPods version 1.16.2

[✓] Chrome - develop for the web [6ms]
    • Chrome at /Applications/Google Chrome.app/Contents/MacOS/Google Chrome

[✓] Android Studio (version 2025.1) [6ms]
    • Android Studio at /Applications/Android Studio.app/Contents
    • Flutter plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/9212-flutter
    • Dart plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/6351-dart
    • Java version OpenJDK Runtime Environment (build 21.0.6+-13391695-b895.109)

[✓] VS Code (version 1.103.1) [4ms]
    • VS Code at /Applications/Visual Studio Code.app/Contents
    • Flutter extension version 3.116.0

[✓] Connected device (3 available) [6,4s]
    • iPhone 16 (mobile) • 620FF751-F320-4085-915B-D8DA36474288 • ios            • com.apple.CoreSimulator.SimRuntime.iOS-18-5 (simulator)
    • macOS (desktop)    • macos                                • darwin-arm64   • macOS 15.6 24G84 darwin-arm64
    • Chrome (web)       • chrome                               • web-javascript • Google Chrome 139.0.7258.128

[✓] Network resources [1.232ms]
    • All expected network resources are available.

• No issues found!

This is already impacting us on our daily workflows, CI/CD and fixing bugs.

Best regards
Emre Yurtseven

@EmreDET

From the verbose log, it seems the the command is taking ~ 158 seconds to cleanup xcode workspace:

[   +1 ms] Deleting build...
[+1334 ms] Deleting build... (completed in 1.334ms)
[        ] Deleting .dart_tool...
[  +11 ms] Deleting .dart_tool... (completed in 11ms)
[        ] Deleting ephemeral...
[   +2 ms] Deleting ephemeral... (completed in 2ms)
[        ] Deleting Generated.xcconfig...
[        ] Deleting Generated.xcconfig... (completed in 0ms)
[        ] Deleting flutter_export_environment.sh...
[        ] Deleting flutter_export_environment.sh... (completed in 0ms)
[        ] Deleting Flutter.podspec...
[        ] Deleting Flutter.podspec... (completed in 0ms)
[        ] Deleting .flutter-plugins-dependencies...
[        ] Deleting .flutter-plugins-dependencies... (completed in 0ms)
[        ] "flutter clean" took 158.639ms.

You can take a look at what the command does in background which essentially is same as deleting above file contents per:

flutter/packages/flutter_tools/lib/src/commands/clean.dart

Line 47 in 660c234

if (xcode != null && xcode.isInstalledAndMeetsVersionCheck) {

We're using SPM and the latest Flutter Version 3.35.1. If needed I can supply the packages we have in our pubspec.yaml.

@EmreDET Yes, please share the same for further analysis on the reported behavior.

Thank you for your quick response.

pubspec.yaml

environment:
  sdk: ^3.9.0
  flutter: ">=3.33.0"

dependencies:
  flutter:
    sdk: flutter
  flutter_localizations:
    sdk: flutter
  flutter_web_plugins:
    sdk: flutter

  # State / Data
  get: 4.7.2
  get_storage: 2.1.1
  shared_preferences: 2.5.3

  # Permission / Input-Output
  image_picker: 1.2.0
  file_picker: 10.3.1
  permission_handler: 12.0.1
  app_tracking_transparency: 2.0.6+1

  # Utilities
  animations: 2.0.11
  json_annotation: 4.9.0
  intl: 0.20.2
  confetti: 0.8.0

  # Images / Files
  flutter_svg: 2.2.0
  cached_network_image: 3.4.1
  flutter_cache_manager: 3.4.1
  pdf: 3.11.3
  pdf_thumbnail: 0.1.6+1
  open_filex: 4.7.0
  flutter_markdown_plus: 1.0.3
  flutter_dropzone: 4.2.1

  # Layout
  infinite_scroll_pagination: 5.1.0

  # Device
  package_info_plus: 8.3.1
  share_plus: 11.1.0
  app_links: 6.4.1
  path_provider: 2.1.5

  # Internet / Webview / Web
  http: 1.5.0
  url_launcher: 6.3.2
  maps_launcher: 3.0.0+1
  webview_flutter: 4.13.0
  webview_flutter_android: 4.10.0
  webview_flutter_wkwebview: 3.23.0
  connectivity_plus: 6.1.5
  web: 1.1.1
  eventflux: 2.2.1

  # Firebase / Google / Analytics / OpenAI
  firebase_core: 4.0.0
  firebase_messaging: 16.0.0
  firebase_analytics: 12.0.0
  firebase_auth: ^6.0.1
  appsflyer_sdk: 6.17.1
  in_app_review: 2.0.10
  google_sign_in: ^7.1.1
  sign_in_with_apple: ^7.0.1

  # Notification / Audio / Video
  flutter_local_notifications: 19.4.0
  audio_waveforms: 1.3.0
  audio_session: 0.2.2
  video_player: 2.10.0
  chewie: 1.12.1
  vr_player: 0.3.0

  # Location
  geocoding: 4.0.0
  geolocator: 14.0.2

dev_dependencies:
  flutter_test:
    sdk: flutter
  flutter_lints: 6.0.0
  # dart run build_runner build
  build_runner: 2.7.0
  json_serializable: 6.10.0

  # For App Icon: flutter pub run flutter_launcher_icons:main
  flutter_launcher_icons: 0.14.4

flutter_launcher_icons:
  android: "new_launcher_icon"
  ios: "AppIcon"
  remove_alpha_ios: true
  image_path: "assets/icons/app_icon.png"
  min_sdk_version: 24
  adaptive_icon_background: "#00AFD6"
  adaptive_icon_foreground: "assets/icons/app_icon_foreground.png"
  adaptive_icon_monochrome: "assets/icons/app_icon_mono.png"

flutter:
  uses-material-design: true
  generate: true
  assets:
    - assets/images/
    - assets/static/
  fonts:
    - family: Roboto
      fonts:
        - asset: assets/fonts/Roboto-Regular.ttf
        - asset: assets/fonts/Roboto-Bold.ttf
    - family: "Comic Sans"
      fonts:
        - asset: assets/fonts/cs-bold.ttf
    - family: "Obviously"
      fonts:
        - asset: assets/fonts/Obviously-Medium.otf
          weight: 500
        - asset: assets/fonts/Obviously-Black.otf
          weight: 700

Maybe for extra detail, we're using internationalization with intl for german and english (but english is currently manually disabled) and using 3 flavors, beta, production and local. The app was also created way back in flutter 2 but we've had no issues updating it over the years.

The issue has also happened, as I've tried to recreate the app with a new blank project. (All the configurations in ios/, android/ and web/ folders manually adapted as our package's configurations demanded).

I've now seen that enabling SPM back then must have added a bunch of schemes, which we can see in the clean.txt, are triggering the repeated cleaning process.

and some others more, depending if the package is already on SPM or not.

https://github.com/flutter/flutter/blob/660c234bb02e60669d5d02bc814bb65c40b9cff9/packages/flutter_tools/lib/src/commands/clean.dart#L100C9-L106C10

I don't know if that was necessary, as I've checked another project with doesn't them at all.

After deleting them (but not the FlutterGeneratedPluginSwiftPackage one) the cleaning process reduced to about 30-33 seconds.

flutter clean -v

clean.txt

I think about disabling SPM and removing all the config and re-enabling it to try to get to the old slow clean to further investigate this behavior.

After removing all SPM related and confirming that everything still works (app builds and runs).
I've re-enabled SPM and I did not get any more extra schemes this time. I did add it manually though.

My flutter clean takes roundabout 30-40 seconds, which is far better than 150-180 seconds it took before.

What do you think, is the reason for the creation of the extra schemes for the packages?

@EmreDET

Thanks for the update @EmreDET I think it could be related to enabling and disabling SPM. I tried to recreate the behavior by adding all the dependencies you shared earlier and then building the iOS. With SPM enabled, it took flutter clean below time

[ ] "flutter clean" took 322,205ms.

After disabling SPM, building iOS again and then running flutter clean didn't take that long:

[ +1 ms] "flutter clean" took 18,959ms.

My flutter clean takes roundabout 30-40 seconds, which is far better than 150-180 seconds it took before.

This seems to be a drastic change and maybe indicates it is not consistent. But I feel adding lot of dependencies since they are external and also the fact that SPM was enabled. I noticed it did take time for workspace to clean each dependency.
I suggest to keep an eye on this behavior and if you again come across such delayed time to clean the workspace, we can probably take this further to the team for further analysis. What do you think ?

Alright. I'll keep an eye out!

Just as a temp fix for everyone else who stumbles to this "problem" of long flutter clean times.

Try to investigate the added schemes in your XCode Project:

For my case, removing the packages with no Pods project Container helped reduce the time of flutter clean.

The last should only be FlutterGeneratedPluginSwiftPackage checked

And above all, you should see your own flavors checked and as Runner project

Based on above findings and per my earlier verifications, I'll keep the issue open and label for team's input on this.

Hey!

I’ve opened a PR that adds a new --xcode-clean option to flutter clean, providing better control over Xcode workspace cleanup, especially for large SwiftPM-based projects.

In my local setup, using --xcode-clean=app significantly reduces the time spent on Flutter clean by avoiding serial Xcodebuild clean runs for non-application schemes.

The change is ready on my side.
I noticed the tree is currently red, so I’m waiting for it to go green before proceeding further.

Would really appreciate any early feedback on the API or heuristics while we wait for the tree to be fixed.
Thanks!

For large projects, running flutter clean --scheme Runner can help

I am also facing the issue of a massive slowdown of flutter clean. Let me provide some info:

I am working on a flutter app for iOS and Android with three build flavors (each with debug, profile and release configs), about 440k LOC (or 250k counting only dart) and a roster of a few dozen package dependencies including usual things like firebase_messaging, flutter_secure_storage, package_info_plus, camera, flutter_webrtc, freezed etc. etc.

Currently we are using Flutter 3.41.6, tried the migration to Swift Package Manager (auto migration worked, pretty smooth 👍 ), but the time taken for flutter clean went from about 7 seconds to about 7 minutes! This is reproducible going back and forth between commits before and after the migration to SPM (and usage of SPM was set at project level with enable-swift-package-manager: true in the pubspec.yaml). Some observations from comparing the outputs of flutter clean --verbose before and after the commit with the SPM migration:

The first significant slowdown is in xcodebuild -list, namely before SPM: 701 ms

xcodebuild-list.txt

vs. with SPM: 40593 ms

xocdebuild-list-SPM.txt

The repos in "Updating from..." match those in the Package.resolved files added by the SPM auto migration.
The added schemes seem to be a subset of Podspecs removed from iOS/Podfile.lock by the SPM auto migration.

Each scheme is cleaned, each time taking 10 times longer than before the SPM migration, and of course the number of schemes has increased significantly. One example (of one of the schemes that already existed) before: 1550 ms

clean-flavor1.txt

and after SPM migration: 15139 ms

clean-flavor1-SPM.txt

And then the output from cleaning one of the newly introduced schemes, less text, but similarly slow: 12936 ms

clean-audio-session-SPM.txt

Running some of those commands on their own, e.g. /Applications/Xcode.app/Contents/Developer/usr/bin/xcodebuild -workspace /Users/user/path_to_app_repo/ios/Runner.xcworkspace -scheme audio-session clean in the iOS directory, it seems that resolving the package graph is the step that takes a lot of time.
This is confirmed by:
time /Applications/Xcode.app/Contents/Developer/usr/bin/xcodebuild -resolvePackageDependencies -workspace /Users/user/path_to_app_repo/ios/Runner.xcworkspace -scheme audio-session which takes about 10 seconds.

Also it seems that the list of resolved packages repeats, with the same content but in a different order. If indeed resolving is the slow step, maybe there could or should be some sort of caching of the results?! Even if resolving package dependencies takes 10s for one scheme, not repeating this step for each scheme (29 in the above example) would reduce flutter clean times from abysmal to a little worse than before SPM. :)

Edit/P.S.: https://github.com/jakobleck/spm_performance_playground for reproduction... ;)

@darshankawar

@darshankawar Is somebody looking into this at the moment? IMHO this is a significant issue and should ideally be fixed (or improved) within the next few months, given that for example Firebase will stop delivering updates to Cocoapods in October (cf. https://firebase.google.com/docs/ios/cocoapods-deprecation) and Cocoapods as a whole will be read-only by the end of the year.

Thanks for the detailed breakdown — the measurements around xcodebuild -resolvePackageDependencies and per-scheme repetition are especially helpful. This does look like a real regression introduced by the SPM migration path, likely due to repeated dependency resolution instead of reusing cached results. I’ll follow along and see if there’s any existing tracking or mitigation for caching across schemes 👍

…

On Wed, Jul 1, 2026, 8:26 AM jakobleck ***@***.***> wrote: *jakobleck* left a comment (flutter/flutter#173940) <#173940 (comment)> @darshankawar <https://github.com/darshankawar> Is somebody looking into this at the moment? IMHO this is a significant issue and should ideally be fixed (or improved) within the next few months, given that for example Firebase will stop delivering updates to Cocoapods in October (cf. https://firebase.google.com/docs/ios/cocoapods-deprecation) and Cocoapods as a whole will be read-only by the end of the year. — Reply to this email directly, view it on GitHub <#173940?email_source=notifications&email_token=CC26EFIJBJWGQJ2GB4OYLH35CUGRZA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTIOBVGU2DEMZXGI22M4TFMFZW63VKON2WE43DOJUWEZLEUVSXMZLOOSWGM33PORSXEX3DNRUWG2Y#issuecomment-4855423725>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/CC26EFJ6OCKM6MUB3Z7D5HT5CUGRZAVCNFSNUABEKJSXA33TNF2G64TZHMZTCNZZGI4DENB3JFZXG5LFHMZTGMRZGMZTGMBXGGQXMAQ> . Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS <https://github.com/notifications/mobile/ios/CC26EFJJWEB7MLO256PMPG35CUGRZA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTIOBVGU2DEMZXGI22M4TFMFZW63VKON2WE43DOJUWEZLEUVSXMZLOOSVGM33PORSXEX3JN5ZQ> and Android <https://github.com/notifications/mobile/android/CC26EFICXIVBHRKA74F4ESD5CUGRZA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTIOBVGU2DEMZXGI22M4TFMFZW63VKON2WE43DOJUWEZLEUVSXMZLOOSXGM33PORSXEX3BNZSHE33JMQ>. Download it today! You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

The issue seems to be (EDIT: only partially) resolved, at least for the reproduction example I posted above, in Flutter 3.44 (I assume through #183747).

@jakobleck

@jakobleck my flutter clean still takes long times. I'm on Flutter 3.44.7, the most latest version.

flutter clean

$ time flutter clean              
Cleaning Xcode workspace...                                       173.3s
Deleting build...                                                   5.4s
Deleting .dart_tool...                                              70ms
Deleting ephemeral...                                                2ms
Deleting Generated.xcconfig...                                       0ms
Deleting flutter_export_environment.sh...                            0ms
Deleting Flutter.podspec...                                          0ms
Deleting .flutter-plugins-dependencies...                            0ms
flutter clean  142.10s user 46.61s system 105% cpu 2:59.25 total

xcodebuild -list (inside the ./ios directory)

xcodebuild -list  56.68s user 34.98s system 246% cpu 37.135 total

@yurtemre7

@yurtemre7 My bad. I only performed the SwiftPM migration for MacOS in the example project (i.e. not started the app on iOS after introducing the setting enable-swift-package-manager: true). So it seems that the issue is partially fixed, that is, flutter clean is quick again with Flutter 3.44 for MacOS-only-migrated projects, while for iOS performance of the clean is still bad. And when performing the SwiftPM migration for MacOS only, it seems that afterwards in the macos folder xcodebuild -list is still pretty slow, so the first clean or build would be slow and then caching mitigates the problem for later cleans.

Make Xcode workspace cleaning optional during flutter clean (flutter#…

Revert: Make Xcode workspace cleaning optional during flutter clean (f…

Reland "Make Xcode workspace cleaning optional during flutter clean" (f…

Same here, it takes up to 90 seconds for a small project. It was under 10 seconds before.

Flutter 3.47.0 is a big improvement towards old behavior.

Edit, 3.47.1 as well way better than 3.44.x:

Cleaning Xcode workspace...                                        22,2s
Cleaning Xcode workspace...                                         4,9s

in 3.47.1, still same

% flutter clean
Cleaning Xcode workspace...                                       178.2s
Deleting build...                                                   8.3s
Deleting .dart_tool...                                             108ms
Deleting ephemeral...                                                8ms
Deleting Generated.xcconfig...                                       0ms
Deleting flutter_export_environment.sh...                            0ms
Deleting .flutter-plugins-dependencies...                            0ms

@EmreDET

Note that comment below was written with the help of github copilot, and reviewed and modified by me

darshankawar If this kind of comment is too verbose, let me know and I will avoid it in the future 😅

Adding a data point from a large SwiftPM workspace, plus what I believe is the concrete root cause and a targeted fix, since this is still unresolved as of 3.44.x/3.47.x.

Summary

flutter clean takes ~62 minutes (45s per scheme x 81 schemes) on our iOS app. The cause is that _cleanXcode runs one xcodebuild clean per scheme, and after the SwiftPM migration Xcode auto-creates one scheme per Swift package product. Our workspace reports 81 schemes, of which only 4 are actually defined by the project.

This confirms what @EmreDET and @importRyan identified earlier in this thread — I'm adding measurements and a concrete patch proposal.

Environment

Flutter 3.44.9 • channel stable
Framework • revision 6b182d2c75 • 2026-08-05
Engine • hash b9499e4c25212536ba3a4eec4f5c1905fb3214fe (revision 5a2a6a42cc)
Tools • Dart 3.12.2 • DevTools 2.57.0
Xcode 26.4.0 • macOS (Apple Silicon)

Why the loop is redundant

Three independent reasons the extra ~77 cleans do no useful work:

1. Only 4 of the 81 schemes are real.

2. Cleaning the app scheme already cleans the packages. Runner.xcscheme has buildImplicitDependencies = "YES", so xcodebuild -scheme Runner clean transitively cleans every package Runner depends on. The per-package cleans are pure duplication.

3. Many package schemes cannot even be cleaned. For example:

xcodebuild: error: Scheme Amplitude-Swift is not currently configured for the clean action.

We pay ~26s for that invocation and it fails.

The dominant per-invocation cost is that each xcodebuild re-opens the workspace and re-resolves the whole SwiftPM package graph.

Things that do not work (so they can be ruled out)

I checked a few plausible mitigations before concluding this needs a tool-side fix:

It is not repeated -resolvePackageDependencies. prefetchSwiftPackages is guarded by if (_swiftPackageFetchProcess != null) return;, so Flutter resolves once. The cost is genuinely 81 × xcodebuild clean. (Noting this because Warn about slow SwiftPM downloads and centralize SwiftPM cache #183747 helped here but did not address the loop, which matches @jakobleck's "only partially fixed" observation.)
Scoping to the project instead of the workspace does not help. xcodebuild -project Runner.xcodeproj -list still returns all 81 schemes (and took 2m28s), because the packages are dependencies of the .xcodeproj, not only of the workspace.
Disabling scheme auto-creation does not help. Setting IDEWorkspaceSharedSettings_AutocreateContextsIfNeeded = false in Runner.xcworkspace/xcshareddata/WorkspaceSettings.xcsettings had no effect on xcodebuild -list — it only affects the IDE.

Manually deleting the auto-created schemes (as suggested earlier in this thread) is not a durable fix for us: they come back, and hand-editing scheme state across a large team is not practical.

Proposed fix

Restrict the loop to schemes the project actually defines, rather than every scheme the workspace reports. XcodeProjectInfo already parses targets, so this needs no additional xcodebuild invocations.

In clean.dart:

} else {
  for (final String scheme in _schemesToClean(xcodeProject, projectInfo)) {
    await xcodeProjectInterpreter.cleanWorkspace(...);
  }
}

/// Xcode auto-creates one scheme per Swift package product. Cleaning them is
/// redundant: app schemes build with `buildImplicitDependencies`, so cleaning
/// those already cleans every package they depend on. Some package schemes
/// aren't even configured for the clean action.
Iterable<String> _schemesToClean(XcodeBasedProject project, XcodeProjectInfo info) {
  final Directory sharedSchemes = project.xcodeProject
      .childDirectory('xcshareddata')
      .childDirectory('xcschemes');
  final onDisk = <String>{
    if (sharedSchemes.existsSync())
      for (final FileSystemEntity f in sharedSchemes.listSync())
        if (f.basename.endsWith('.xcscheme'))
          f.basename.substring(0, f.basename.length - '.xcscheme'.length),
  };
  final candidates = <String>{...onDisk, ...info.targets}
      .intersection(info.schemes.toSet());
  // Fall back to existing behaviour if the heuristic finds nothing.
  return candidates.isEmpty ? info.schemes : candidates;
}

On our project this selects 5 schemes instead of 81 — ~62 min → ~4 min — while still covering flavor schemes such as dev that a target-name-only filter would miss. The fallback preserves today's behaviour for projects where the heuristic yields nothing.

Union of on-disk schemes and targets (rather than targets alone) matters: flavor schemes like dev are shared schemes with no identically-named target, and they do need cleaning.

One caveat: this assumes auto-created package schemes are never written into xcshareddata. That held on our project. A project that deliberately commits a package scheme would still clean it — harmless, just slower.

Simpler alternative: drop -workspace/-scheme and run xcodebuild -project Runner.xcodeproj clean once, since a project-scoped clean with no scheme cleans all targets in a single invocation. But that stops cleaning Pods, so it can only be used after Flutter fully drops pods support.

Workaround for others landing here

flutter clean --scheme Runner cuts this from ~62 min to ~1 min for us. (Thanks @iamgirya)

Navigation Menu

Repository navigation

Flutter: Cleaning Xcode workspace takes 2-3 minutes #173940

10 remaining items

Summary

Environment

Why the loop is redundant

Things that do not work (so they can be ruled out)

Proposed fix

Workaround for others landing here

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Flutter: Cleaning Xcode workspace takes 2-3 minutes #173940

Description

Activity

darshankawar commented on Aug 18, 2025

EmreDET commented on Aug 18, 2025

EmreDET commented on Aug 18, 2025

EmreDET commented on Aug 19, 2025

darshankawar commented on Aug 19, 2025

EmreDET commented on Aug 19, 2025

darshankawar commented on Aug 19, 2025

10 remaining items

RusKryzhanovskiy commented on Jan 16, 2026

iamgirya commented on Mar 13, 2026

jakobleck commented on Jun 4, 2026

jakobleck commented on Jul 1, 2026

vaydenloren-design commented on Jul 1, 2026

jakobleck commented on Jul 21, 2026

yurtemre7 commented on Jul 21, 2026

jakobleck commented on Jul 21, 2026

intraector commented on Aug 19, 2026

JakobLichterfeld commented on Aug 19, 2026

NewLand-Ju commented on Aug 20, 2026

gabrielgarciagava commented on Sep 2, 2026

Summary

Environment

Why the loop is redundant

Things that do not work (so they can be ruled out)

Proposed fix

Workaround for others landing here

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions