This has started happening again today, we're observing builds queued for > 30 minutes right now. @Developer Tools Engineer

We started facing the same issue today. Builds are queued up for over 30 minutes and they run forever with no end. Our builds usually take ~12 minutes to complete, so I guess something's broken on Xcode Cloud. Hoping for a quick fix because we rely on it to ship updates! 🤞

Turns out, this was my own issue! I was passing the schema on both ModelConfigurations, when I should be passing a different Schema for each configuration, and then a Schema that contains everything to the ModelContainer init. I made such change, and now it works as expected, only the LTRLink appear on iCloud's console!

Hey @DTS Engineer, thanks for your response! I do believe this should work as expected (no hang whatsoever) without the need for pagination. On UIKit + CoreData you don't need pagination, using an NSFetchedResultsController allows you to display as many items as you wish on a UITableView/UICollectionView without any hangs whatsoever. I've filed FB15507372 and put up the project for anyone to download and run here so it's easily reproducible: https://github.com/xmollv/SlowData

After more digging, it looks like List is doing the correct thing, but @Query seems to be loading all data up-front. I've enabled the SQL debug logging and I see the following when I tap on the All menu item: CoreData: sql: SELECT 0, t0.Z_PK, t0.Z_OPT, t0.ZISOPTIONA FROM ZITEM t0 ORDER BY t0.Z_PK CoreData: annotation: sql connection fetch time: 0.0025s CoreData: annotation: fetch using NSSQLiteStatement <0x60000622dd60> on entity 'Item' with sql text 'SELECT 0, t0.Z_PK, t0.Z_OPT, t0.ZISOPTIONA FROM ZITEM t0 ORDER BY t0.Z_PK' returned 15000 rows But then if I add a print statement on the init of what would be the row view of each List item, it only calls the init for as many times as rows fit on-screen. So, my final question is: If the fetch to the database is pretty much instant, and List only loads the cells that are visible on-screen, why there's such a massive hang? If instead of using @Query I simply pass 15_000 Items, there's no hang. But the fetch seems extremely fast, so I'm really confused at where's the problem. Gist with the code: https://gist.github.com/xmollv/e682ad6c22ac0bfd4b410e9fdb6db5c4

We're experiencing the same issue. Started like 4 hours ago and doesn't seem resolved yet. Not all builds fail, but the majority do.

Yeah we're getting the same errors. Also stuff like this:

This seems to be related to the fix on 'Thread Performance Checker': https://developer.apple.com/documentation/xcode-release-notes/xcode-15_3-release-notes#Thread-Performance-Checker If I disable it on the running scheme, the CPU spike is gone. Since the backtrace seems to be all internal to the OS (no calls to our app are being logged), it doesn't look like there's anything I can do until Apple fixes it internally, right?

Okay ignore me. Apparently Xcode Cloud recently changed and added a 'Manual Build' trigger option. We were using a disabled workflow before with the trigger on a branch changes. We were starting builds manually by running one on them and picking the branch we want. The moment I removed that trigger and replaced it for the 'Manual Build' one, the branches started appearing again!

I sort of fixed it by nuking everything. One one of the apps, I clicked on 'Delete Xcode Cloud Data'. Then I recreated the workflows because everything is gone (we just had one, so it was simple to do on that one) and now it shows new branches again. Is there no way to fix this other than re-configuring the whole thing? The other apps I mentioned have much more complicated workflows that will be really painful to re-create again...

I'm having the same issue.

This seems to have resolved itself.

After half a day working, we've seeing that this is intermittent. We've changed nothing and some builds succeed and some fail. Looks like a check on AppStoreConnect somehow is flaky, hopefully it'll be fixed soon. For now we're just re-triggering the builds that fail and they end up succeeding at some point.

I saw on the Fastlane docs that they mention a daily 150 binary limit, but we're definitely very far from that → https://docs.fastlane.tools/actions/deliver/#limit Does anybody know if it's recently been lowered to ~20 or something like that?

Looks like the issue is happening after the build finishes and the artifacts need to be uploaded: