Unfortunately this would not help in my case, since the intend (in the original project) of the _failsafe method is to "recover" from generic server errors and send the original request again. (For various reasons the server I am talking to behaves not as the "normal" REST/HTTP server and there is unfortunately no way to change that.) I am wondering now if there's something wrong about how I am using async/await/URLSession (except from being used in a very contrived example ;-)? To me it seems I am using them in a "legal' way, but for obvious reasons I am just starting to use async/await in Swift ;-). Thanks for your help!

Additional info: If (in the original post) LoginAsync is not an actor, but a class the crash is not happening anymore. Really would like to understand what the root-cause of the issue is...

Thanks for getting back to me! I think I will wait one or two betas (keeping my fingers crossed) before opening a TSI. Thanks for the suggestion!

Still the same behavior, even with waiting. So far all the machines I could reproduce the issue were laptops (MacBooks Pro/Intel/M1/M1 Pro), using the latest macOS, Xcode. Not sure if this is any indicator for anything, but may I ask on which machine you had success? Thank you!

This looks like a good workaround. Unfortunately it does not work for me. See my reply below.

Forgot to mentioned: Using Xcode 14.0 beta 3 (14A5270f)

Perfect. This solved my issue! Thank you!

Thank you! With which iOS version have you tried it. I tried it now with the latest beta and yes it works :-). They seem to have fixed and now I am wondering, if it's only in the latest betas...

Thanks for reminding me how this works! I checked with the iOS 16.0 (for some reasons the version between 16.0 and 16.4 were not available) and there the issue does not occur. So it seems to be a regression in 16.4.1 (or somewhere in between).

Yes, that'll work. Thanks! I think my gripe here with it is more along the lines, that I hope that we need this is just a "Beta issue" and we do not need such kind of boilerplate code in the final version.

Thank you!. Do you know if this("... must be optional) is documented somewhere or mentioned in one of the WWDC sessions? Because while it makes it work, it also changes the semantics of the model: With making it an optional "group" is no longer a required relationship, which is what would be correct for my model.

This would not work, since the group attribute of Person is (intentionally) not optional. This will result in a runtime error at the ctx.insert(person) statement. If it would be optional, then it will work.

"if your list view wanted to use what was the new object created in your list view [...]" Another approach, instead of using a closure, could be to pass a binding to the new object an an optional (@Binding var newObject: NewObjectModel?). In case of "cancel" nothing would be set, so it would still be nil. And the case of save it would be set to the newly created model object and the calling view could react on that (for example with the onChange modifier).

You could make a DeckList View which would have the @Query var decks: [Deck]. There you could use for example a List and inside the List use your DeckRow with a single Deck as a parameter (the @Query should not be in the DeckRow anymore - replace is with var deck: Deck).